journal/2021-03-14--13-00-04Z--the_service_pattern.org

journal/2021-03-14--13-00-04Z--the_service_pattern.org

@@ -126,54 +126,10 @@ Architecture while moving a component.
 
 The service pattern should be easy to grasp with a few concrete examples.
 
-Imagine you want to design an interface to manage your users.
-The API you want to provide might be a very minimal CRUD-like one.
-
-- =create-user=
-- =read-user=
-- =update-user=
-- =delete-user=
-
-Behind the scene you would like a DB to save and access your users.
-But hey, you also have a quite similar interface for many other entities of
-your system.
-For example =books=, =movies=, etc...
-Also you  might want to support different DB.
-Most DB shoudl support these basic CRUD accesses.
-So you create an intermediate store layer.
-
-That layer will take a configuration like: DB-type, DB-configuration
-and given this configuration provide a CRUD interface.
-
-So basically you could write something like:
-
-#+begin_src javascript
-require MyCRUD
-
-// evil global variables
-var usersCRUDAPI = nil;
-var booksCRUDAPI = nil;
-
-function application_init() {
-  usersCRUDAPI = MyCRUD(db = "postgresql", db_conf = { table:"users", url:... })
-  booksCRUDAPI = MyCRUD(db = "elasticsearch", db_conf = { index:"books", url:... });
-  ...
-}
-
-function main() {
-  // evil init with side effect
-  application_init();
-  do_shit();
-}
-
-function do_shit() {
-   user = usersCRUDAPI.getUser("my_user");
-   booksCRUDAPI.createBook({title:"Book Title", owner:user.user_id })
-}
-#+end_src
-
 So the Service Pattern you split your application in components with
 internal state and a clear interface.
 It looks a lot like OOP but it isn't.
 The inner state is global unlike in OOP where every object has an internal
 state.
+So the number of isolated state should not grow dynamically but should be
+mostly static after the runtime init.