A hardware engineer look at code architecture.
Thomas Depierre
@Di4naO
DianaOlympos
@di4na
Twitter :
Github :
Slack :
Maths and Physics
Caml
Hardware (C, VHDL, ...)
Data Analysis
Elixir for fun
What is an engineer ?
Create a system that is a solution to a problem
How to create something that complex ?
How to create something that complex ?
- Separation of concerns
- Known reusable components
- Clarke's third law
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's third law
Why talk about it ?
-
Code is a possible solution to a problem
-
You build systems
-
Existing corpus about engineering, and not only about technological solution
-
Human Factors is an engineering field
-
-
Because as a Hardware engineer, OO never stuck in my original field
-
Because Erlang/OTP are an engineer solution
Erlang/OTP : for engineers
- Find a solution for engineers to build systems with real constraints
- Not a CS thing
- Try, test, move or keep
I want to stay away from the obvious: ‘concurrency, yay!’ One thing I’m really interested in is how Elixir can help make architectural decisions easier.
Let's go into the real thing
Data in, transform, Data out
Let's have a look at OTP
Nothing about the outside world. Sorry.
Not really nothing no...
In
Well known structure. Decide the protocol
Transform
Ecto
Phoenix
Cowboy
...
OTP Behavio(u)rs
- Separation of concerns :
- independant
- isolated
- Known and reusable :
- common interface
- common callbacks
- Magic :
- Edge case handling done by experts
- separation of concerns by abstraction
From top to bottom
-
Application
-
Supervisors
-
Process
-
gen_server
-
gen_statem
-
sys
-
...
-
Application
- Known component
- Independant from your app
- A full Service, battery included
- Node level
In a factory, it is a service, a unit.
Supervisor
- Put the workers at work!
- Handle the dirty stuff : Who dies !
- Orthogonal from your data flow
- Kind of...
- Linked to the structure of your app
- But don't interact with the work being done
Just like in a Factory...
Process
- Handle the data flow.
- What goes where
- How to transform
- Respect the principles too, at a lower level
- Hide their interiors through Client API
Your workers
Can be specific to your app or a known behaviour.
Hint: you probably want one of the generic behaviour
How to use it?
Think in term of service!
- Is it used in more than one place ?
- Does it handle it's own data ?
- Is it modifying data ?
- Could it be an independent piece of software ?
If you answer yes to any of these questions, you got a service.
How to use it?
Think in term of service!
- Each of these piece get its own folder in /lib
- Dedicated supervisor sub-tree
- Define a struct for your data inside that service
Example_service
supervisor.ex
random_gen_server.ex
How to use it?
Think in term of service!
- Each of these piece get its own folder in /lib
- Dedicated supervisor sub-tree
- Define a struct for your data inside that service
Example_service
supervisor.ex
random_gen_server.ex
Why use that architecture ?
- You can extract that part easily later
- Transform it into a library
- or an application
- or a dedicated node
Why use that architecture ?
You can even add an interface and get a microservice !
It is all the same thing. Define the business logic.
Use a layer of abstraction on top with a client API.
Supervisors
Supervisors are orthogonal to your data flow and business logic !
But not really
They define the boundaries of your services
They are helping in architecturing !
Common Gotchas
- Ecto is not your app. It is a connection to the outside
- Phoenix is not your app. It is... a connexion to the outside ...
Common Gotchas
- Supervisors are not here to handle data flow
- Try to hide your OTP behaviours behind Client API
- So please no GenServer.cast in the middle of code
Common Gotchas
- Applications everywhere !!!
- Put all your dependencies in applications
- If you have multiple things, you can look at Umbrella.
Thank you for listening
Questions ?
A hardware engineer look at code architecture.
By di4nao
A hardware engineer look at code architecture.
- 759
