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

#+TITLE: The Service Pattern
#+Author: Yann Esposito
#+Date: [2021-03-14]

- tags :: [[file:2020-06-03--19-49-30Z--programming.org][programming]] [[file:2020-05-26--06-13-41Z--functional_programming.org][functional programming]] [[file:2020-05-26--06-16-14Z--clojure.org][clojure]] [[file:2020-05-26--06-19-53Z--haskell.org][haskell]]
- source ::
- related :: [[file:2020-12-23--16-50-17Z--effects_system_in_clojure.org][Effects system in Clojure]]

* Introduction


The question about code structure and organization is one of the most
prolific one.
The problem are always the same.

Here I will talk about one possible solution in this huge design space.
First of all, I will focus on a functional programming pattern.
But I think the lessons could be extended to any generic programming
language.

Before explaining the pattern I would like to take the time to provide a
few distinctions between different programming language patterns.
Quite often, one fundamental question very important when choosing a
pattern for your code is about find the correct level of the pattern.

There are a tower of patterns and meta-patterns.
For example in imperative programming not using =goto= statement was
considered as a programming pattern.
Once that idea was accepted there were work done on /Object Oriented
Programming/.
And OOP was considered as a programming language pattern.
But OOP while already providing quite a constraint on your code
architecture was enough not sufficient.
OOP alone leave a lot of room in the design space.
Thus we've seen numerous "OOP Design Pattern".
That used the underlying OOP paradigm as a base and constructed
abstractions over it.

Even with all those Design Pattern it was up to the programmer to decide
which one applies or not.
Quite often there is not a single path easy to detect correct design
pattern.
Mainly the very hard part in programming is choosing the right abstraction.

There are other code structures to choose from.
In functional programming there are FRP.
Here also there are stories about how design pattern once chosen make a
natural evolution toward meta-design-patterns.
Mainly design pattern that rely on a lower level design pattern.

If you take the story behind Elm Architecture you can see it.
At first there were FRP.
Elm removed the behavior from FRP to only deal with events to simplify the
model.
But with FRP the author clearly though it was a good-enough design pattern.
But the design space was a bit too big.
So it was difficult to take the right decision.
So a natural meta-pattern appeared.
It is [[https://guide.elm-lang.org/architecture/][/Elm Architecture/]].
So while Elm imposed so structure of your program using static types to
prevent common coding mistakes and enforce a specific code structure.
Elm did not constrain the file organization, the number of buffers to
send/receive events, the way they should talk/listen between each other.

So Elm Architecture is a non enforced meta structure for your code
application.
Unlike the underlying layer of architecture.
But what Elm Architecture provide is a higher level architecture that will
help your program to "scale" and whose natural organization is easy to
understand.

So Elm Architecture is more of a proposal that will potentially have
drawback.
Typically, if you change the organization of your views, it could cost a
lot of change in your code.
But most of the time this is acceptable and preferable.
Because, the Elm Architecture is simple to understand and quite often this
is not such a big deal.
Not using the Elm Architecture paradigm put you at risk to end up in a
spaghetti code hell.
But of course there is a tension between code size/DRYness and easy to
understand code organization/architecture.

If you have a short code base, DRYness could probably be preferable.
Because a bit of disorganization and shortcuts will not be unbearable.
But as the size of your code grow, it will become more and more prevalent
that a strict code organization with perhaps more repetitions and a bit
more conventions implying more lines of code become preferable because it
minimize the risk of surprise between different part of the code.
Clearly, Elm Architecture is selling compactness of your code for an easier to
read, discover and understand overall code architecture.

So we could probably say the same for multiple proposed code architecture
mechanism in the Haskell world.
Typically we had:

- no org => spaghetti code
- big Monad => lack of composability, leak of abstraction everywhere
- Handler Pattern
- MTL
- RIO
- Free Monads (Effects)

After this first short introduction I hope it is clear that, it will be
quite impossible to discover a "best code architecture".
There are multiple code architecture and the bigger your code the more
constraint you must probably put in your code which will make a lot of code
look cumbersome from people used to smaller code size.

That being said, there are code architecture that could be probably be
considered fully superior to other ones.
Imagine a code architecture with the same properties but better in some
dimensions without worse evaluation in some dimension.
Typically, a code architecture is preferable to no code architecture as
soon as your code become big enough and you need to not work alone.

For example I would argue that the Purescript Halogen architecture is
probably strictly superior to the Elm Architecture.
Because it contains Elm Architecture but also contains a shortcut mechanism
which is entirely enforced via static types..
The "cost" of these shortcuts are quite limited because you are helped with
the types provided by the Halogen framework.
One big advantage is the ability to not pay the full price of the Elm
Architecture while moving a component.
* The Service Pattern-level 1

The service pattern should be easy to grasp with a few concrete examples.

Imagine you need to