[erlang-questions] Separating Functionality

[Robert Raschke]

Further, a "module" is a code organisational thing, "applications" and
similar OTP entities, like "supervisor", "gen_server "or "gen_statem", are
runtime things.

Thus, an "application" is made up of a bunch of "modules" that implement
either libraries of functions and/or processes that that do stateful work
(usually implemented using "gen_..." frameworks).

On Wed, 29 Aug 2018 21:50 Robert Raschke, <rtrlists@REDACTED> wrote:

> The main equivalent of a microservice is what Erlang calls an
> "application". This is an entity that you are supposed to be able to start,
> stop and up/downgrade as a thing in its own right. And it may depend on
> other "applications", in turn it may be depended upon, or it can be
> independent or even just a stateless library.
>
> Multiple "applications" make up your system, called a "release" in Erlang.
> Whether your "applications" are distributed across multiple nodes or not is
> up to you.
>
> On Wed, 29 Aug 2018 19:50 Code Wiget, <codewiget95@REDACTED> wrote:
>
>> Hi everyone,
>>
>> With many programming languages, it is easy to think of ways to separate
>> projects into distinct micro services. With Erlang, I'm having trouble
>> deciding on how to spread out functionality. Because the Erlang VM can run
>> multiple different fully independent applications, it seems tedious to spin
>> up 5 different Erlang VM’s to do different things when it could all be
>> accomplished on one.
>>
>> At the same time, as you scale, you probably want to separate
>> functionality…
>>
>> So, do you have a rule of thumb or rules by which you decide on how to
>> separate functionalities into modules vs applications vs entire releases?
>>
>> Thanks!
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180829/993e1319/attachment.htm>