[erlang-questions] Multiple Applications

[Jay Nelson]

The key to architecting erlang systems is understanding the difference
between applications and supervised processes. The important
characteristic is what you would expect to happen in the case of a
failure.

Applications:
    - If permanent, failure takes down the VM node
    - If temporary, failure has no other implications
    - If transient, failure other than normal kills the VM
    - There is no automatic restart of an application

Supervised processes:
    - Failure is communicated to the supervisor
    - Automatic restart is dictated by supervisor strategy
    - Startup order is dictated by the supervisor hierarchy

In general applications have no order dependency (you can see
this when code has things like application:start(crypto) littered
about or have a function called 'ensure_started') other than the
initial serial order listed in the applications list.

A better approach is to make separate applications which
have an app.erl and a single root supervisor which manages
and describes the restart strategy for components of each
application. Then an overarching application would include
all subordinate applications so that they can be managed
and restarted if they fail.

For your composite top-level application you use
the include_applications property (rather than the
applications property to list the subordinate applications).
Start phases are used for ordering dependencies on
any synchronized startup that is needed across the
applications. The root supervisor of the composite
application should start the corresponding root
supervisors (anywhere in the supervisor hierarchy
that makes sense) of the subordinate applications.
The composite supervisor hierarchy will enforce
any restart dependencies and start up ordering, and
the start phases will enforce any post start up initialization
such as launching one-for-one workers, connecting to
databases and so on.

My recommendation is a single application with supervised
and included applications, although this is not common in
open source projects.

jay