On Thu, Jan 26, 2017 at 3:45 AM, Charles Shuller
<[hidden email]> wrote:
> What things should be considered when deciding if a chunk of functionality
> should be implemented as a plain old module or a gen_server??
Think of the process(es) which will execute the code providing the
functionality. If existing processes will call functions in your
module and execute that code inline than it is a library module and
needs no behavior.
If the functionality will be provided by executing the code in a new
process than you should consider how you will handle system messages
in that process. If you don't yet know what that means you should use
one of the standard behaviors which will provide everything you need
to behave correctly in OTP. If you don't like to play it safe you can
handle system messages in a "plain old module"
The more common question is: should I use a gen_server or a gen_fsm
(or gen_statem) behavior? If you start with a gen_server and later
realize you need to handle an event differently based on something in
a previous event than your server has states and you should port it to
a gen_fsm (or gen_statem).
On Thu, Jan 26, 2017 at 5:20 AM Charles Shuller <[hidden email]> wrote:
What things should be considered when deciding if a chunk of functionality should be implemented as a plain old module or a gen_server??
As a main rule:
Stateless functionality goes into library modules, stateful functionality goes into a gen_server process.
A good example is a database pool. The protocol encoder/decoder for the database is a library and should live separately. A stateful connection to the DB uses the protocol module to provide its functionality. Finally, a separate system handles the pooling and its guarantees.
By splitting the system up, you can reuse the DB connection code in another pool. Or you can move the connection handling into another process by calling directly into the library.
Another main rule:
Each concurrent activity which needs to keep state must have its own process.