So a functional interface is where I’d start. After that I’d begin to add processes as needed. I’d probably not go “all in” with them and introduce one genserver to manage all users, another – to manage all schedules, etc.
Once they become a bottleneck, I’d switch to ets. Once a single ets table for a resource (users, schedules, etc) becomes a bottleneck, I’d start sharding the data among cpu cores (one ets table per cpu).
But the functional interface wouldn’t change. Sure, you can implement everything as a process behind this interface, but what’s the point? It would only increase complexity.
This is impossible to answer. If we take your employees as an example, using one process per employee is likely wrong because it’s hard to argue why you should have one process per employee instead of a single process holding a list of employees. You also want to store schedules, should they be stored separately from employees? Possibly, but what would you gain from that?
Eventually you can consider storing the whole database in one process. What are the benefits and downsides of this? One benefit is less complexity, one process is simpler than multiple, another is that you can more easily implement transactions because you don’t need synchronization between multiple process.
One downside can be seen as an code organization, all your database would be in one location, but this is the misconception. Code is organized with modules, so you can have multiple modules for one process. Another downside can be scalability, you may want to shard your database to multiple process so you can use all your cores. This is when you should start considering using multiple process.
So to summarize, it is hard to answer this question because you are asking how to structure an application using processes when we are saying that you shouldn’t. I would suggest that you start writing the application without processes or with a single process and then when you hit a road block that you think processes will solve come back and ask a question that is specific to your problem and less abstract and hypothetical.
Thanks for your feedback. Again, I’m not building anything. Just a purely conceptual question that popped onto my head after listening to some Erlang developer talking. He does everything in gen_server processes — I’m curious as what that looks like.
My Elixir applications are traditional (if we even have such a thing yet). I was listening to an Erlang programming talking about how he does not use databases and evading is a process (gen_server) to store state — essentially replacing the database.
So to summarize, it is hard to answer this question because you are asking how to structure an application using processes when we are saying that you shouldn’t.
This is what has me highly curious what that looks like translated to Elixir. I think you’re right there is no right answer really.
The two major models are to map data to process or task to process.
For example: a chat app would likely have a process per person (data) while a banking app a process per debit/credit transaction (task). This allows you to expand the relevant bottleneck i.e. add more transaction tasks independently.
Processes can be rich or thin. A rich process would accept a wide range of messages that call out to other modules (not necessary other processes). A person process is a good example of this.
Task processes tend to be thin and focus on specific messages and to interact with other processes.
On the larger architectural front, splitting into nodes and applications is key. Fortunately it is easy to begin either top-down or bottom-up when designing the architecture.
You might reference the talk so we can be on the same page with you. My guess, is that the application he is talking about is not some CRUD application manipulating and storing business data. More likely it is a soft real-time application, such as may be used in the control plane of a network appliance, or even a manufacturing facility. There is no abstract “best way” to structure such applications - it is all very specific.
I think you’d be better off if you tried to solve a problem that actually needs concurrency at it’s core, like writing a reliable message queue consumer or a web crawler.
Employees, timecard events, schedules, vacations, and overtime may be important concepts for structuring data and possibly even parts of application state but really don’t inform much in terms application behaviour.
I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging” …
This comment highlights how people like to focus in on (static) “objects” because that is comparatively easy when in fact the application value is derived primarily by the (dynamic) “collaborations” that implement application behaviour.
Similarly in a BEAM application the ideal process structure is influenced much more heavily by the behaviour the application is meant to exhibit rather than the structure of the data it is managing or transforming.
This Erlang developer puts a different spin on it: Lambda Days 2015 - Torben Hoffmann - Thinking like an Erlanger
Processes as the building blocks for protocols - so the big idea is designing protocols realized through communicating processes to implement application behaviour.
