[elm-discuss] Status update and multiple application servers

[m***@gmail.com]

Sorry I'm only a beginner and I need to understand this thing at the level of software architecture.

If I'm not wrong, status management (or more generally application logic) is implemented in Elm on server side (as opposite to other JavaScript frameworks running on client side).

Then how is status consistency guaranteed in a professional enterprise environment, in case of load balancing, multiple application servers, etc... What if the previous message hits a server and the next another one?

[Matt Hughes]

Hi, Elm programs are compiled to JavaScript and run in the browser, not on
the server. Elm provides libraries for using HTTP and WebSockets to
exchange information with a server. Elm is just the programming language,
so load balancing, application servers, and so on are out of scope for this
group. Standard web application architecture practices apply.

mch

Post by m***@gmail.com
Sorry I'm only a beginner and I need to understand this thing at the level
of software architecture.
If I'm not wrong, status management (or more generally application logic)
is implemented in Elm on server side (as opposite to other JavaScript
frameworks running on client side).
Then how is status consistency guaranteed in a professional enterprise
environment, in case of load balancing, multiple application servers,
etc... What if the previous message hits a server and the next another one?

[Charles Scalfani]

While it MAY be true that server side Elm is out of scope for this group (although it should not be), Elm can definitely be deployed on the server. In fact I've been writing Elm since 0.17 and it primarily on the server side.

['Rupert Smith' via Elm Discuss]

Post by m***@gmail.com
Sorry I'm only a beginner and I need to understand this thing at the level
of software architecture.
If I'm not wrong, status management (or more generally application logic)
is implemented in Elm on server side (as opposite to other JavaScript
frameworks running on client side).
Then how is status consistency guaranteed in a professional enterprise
environment, in case of load balancing, multiple application servers,
etc... What if the previous message hits a server and the next another one?

The concept of a 'single point of truth' comes into play here.

For some given piece of data, there needs to be just one place in your
architecture that holds the definitive state of that piece of data.

Some examples of how this can be achieved:

* A database that is shared across the application servers.
* Sessions that are serializable and can be moved to whichever application
server processes the request. Some kind of fast distributed store may be
used for this purpose.
* Sticky sessions. The same sessions always comes back to the same server,
making it simpler to guarantee a single point of truth.