[erlang-questions] Architectural quandaries

[David Welton]

Hi,

On Thu, Sep 11, 2014 at 4:28 PM, Jay Nelson <jay@REDACTED> wrote:
> David Welton wrote:
>> I'm still struggling a bit with some doubts about how to best
>> architect a complex, real-world Erlang application.

> Let it crash serves a purpose when you have complex code, but somewhere
> at the base you want some sense of stability, especially in a loosely coupled
> environment.
>
> I would focus on a simple core that starts up and connects things. This core
> should have a very reliable low level signal between server and tablet that
> it is in one of a few states: started, connecting, disconnecting, running, etc.

Yes, that sounds sensible.

> When all else is going haywire, this core needs to at least indicate to the
> tablet so you can give feedback to the user. For continuity, some data
> should be cached on the tablet after connecting / running, so that intermittent
> failures can be smoothed over in the user’s eyes. Just because the components
> may be currently unstable or reconnecting doesn’t mean the user experience
> has to be.
>
> Recently I have been confronted with the excess complexity of our systems
> and have been sketching out new approaches to bring up and down systems
> in a more controlled manner (and dealing with multi-minute startups in a better
> way). You should consider sketching out a supervisor hierarchy along the lines
> of:
>
> 1) Rest_for_one root children
>       - this guarantees startup ordering
>       - allows later children to make assumptions
>
> 2) Start fast core things early
>      - included base libraries with no real initialization
>      - required ets tables (you might want to cache send to / recv from tablet events)
>
> 3) Start an FSM to control startup
>      - use messages to this to start / stop children of other supervisors
>
> 4) Rest of the supervisors with no children
>      - if possible one_for_one under a single last rest_for_one supervisor
>      - add start_child / stop_child functions and call these from the FSM
>
> Root (rest_for_one)
>     - libs
>     - pre-allocated resources
>     - FSM
>     - Services (one_for_one)
>          - Service 1..N

So you would advocate putting everything in one Erlang 'application'
in order to take advantage of the restart capabilities such as
rest_for_one?  I was actually moving to break things up into separate
applications with different git trees and everything, so that things
could be developed in a more independent way: for instance, the report
generation software gets its own application, separate from the
hardware control software.

I was starting to think along the lines of a centralized system for
monitoring some of these applications...

-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/