96 lines
3.4 KiB
Org Mode
96 lines
3.4 KiB
Org Mode
:PROPERTIES:
|
|
:ID: cdf1dfad-99f0-42d6-9eda-7a04dd275c20
|
|
:END:
|
|
#+Title: Dynamic Service Architecture for big Software
|
|
#+Author: Yann Esposito
|
|
#+Date: [2024-01-03]
|
|
|
|
- tags :: [[id:a5be1daf-1010-428f-a30f-8faf95c1a42f][blog]]
|
|
- source ::
|
|
|
|
* Introduction
|
|
|
|
???
|
|
|
|
Plan attempt
|
|
|
|
* Plan
|
|
|
|
** Introduction
|
|
Talk about composability in real-word application.
|
|
How we can think of it in a static way vs a dynamic way.
|
|
Why part of dynamicity is mandatory.
|
|
How could this be achieved?
|
|
Maybe talk about meta-programming with yesod for example.
|
|
|
|
** Evolution of Code Architecture
|
|
|
|
Why do we need to provide code architecture patterns?
|
|
|
|
Try and errors, and learning from them.
|
|
By doing so we discovered a few important architecture design patterns.
|
|
|
|
1. spaghetti code. Mix everything, everything is coupled. If you change one line
|
|
of code this will impact other places. Only survival strategy, copy/paste,
|
|
become a master of massive search and replace.
|
|
2. Externalize state. You want to make it a lot easier to scale.
|
|
So you keep your business logic data in an external DB hopefully choosing one
|
|
that could scale. So you could easily spawn a new node and the charge will be distributed.
|
|
This is basic Ops hygiene that gave birth to 12 factor application methodology.
|
|
3. MVC. Once you took care of externalizing the state, you then discover that
|
|
you don't want to mix the business logic with its presentation. So you add a
|
|
view layer. One very nice property of MVC is that it can be organized and
|
|
even better composed in components.
|
|
Each component will provide the three aspects, Model View and Controller. And
|
|
you can create a framework that will compose them.
|
|
4. Last step but not the least, Controllers is where you take care of your
|
|
business logic. And some will share common usage, you naturally ends up with
|
|
building the same common components or libraries.
|
|
So now, you will start to have a lot of components that will not have views
|
|
and only Controller and optionally a Model saved in DB.
|
|
Worse, every of these component have a lifecycle. They start and initialize
|
|
their internal state, then they live, and finally they could be removed and
|
|
be deleted. So you will end up with a complex mess of internal state that is
|
|
not business logic state, but only technical local state.
|
|
To solve this problem you have different architectures proposed but in the
|
|
functional world this could be components.
|
|
So you split your logic into different services. Each of them will take care
|
|
of their own technical internal state.
|
|
|
|
How does this work?
|
|
|
|
** Components / Services
|
|
|
|
Service Lifecycle. Every service pass through different phases.
|
|
|
|
1. init
|
|
2. start
|
|
3. live
|
|
4. stop
|
|
|
|
There is a distinction between init and start which could be useful for some
|
|
technical reason.
|
|
Every component also declare its dependency over other components.
|
|
Every dependency can be either mandatory or optional.
|
|
|
|
On top of this every component also exposes a public API.
|
|
|
|
But that's not all.
|
|
Every component should be organized into:
|
|
|
|
- schemas / data-structure
|
|
- service declaration
|
|
- service implementation
|
|
- optional associated web service declaration / implementation
|
|
- different default configs per option. LOCAL, DEV, CI, TEST, PROD
|
|
- tests:
|
|
- implementation (short)
|
|
- service (big)
|
|
- web service
|
|
- default test configs TEST_SELF_CONTAINED, TEST_INTEGRATION
|
|
|
|
But that's not all. For modern application you need:
|
|
|
|
1. Structured traces/logs
|
|
2. Very good state layer
|
|
3. Centralized business logic
|