Picture. Page Lifetime
N2O request lifetime begins with the start of HTTP process serving the first HTML page. After that it dies and spawns Transition process. Then the browser initiates WebSocket connections to the similar URL endpoint. N2O creates persistent WebSocket process and the Transition process dies.
Your page could also spawn processes with wf:async. These are persistent processes that act like regular Erlang processes. This is a usual approach to organize non-blocking UI for file uploads and other time consuming operations.
HTTP handler will die immediately after returning HTML. Transition process stores actions and waits for a request from a WebSocket handler.
Transition process is only applicable to dynamically rendered pages served by n2o_document endpoint. You never deal with it manually.
This code will register all WebSocket processes under the same topic in pubsub and broadcast history changing to all registered process in the system under the same topic using #flush NITRO protocol message.
During page initialization before Module:event(init), Module:main/0 is called to render initial postbacks for elements. So you can share the same code to use SPA or DSL/DTL approach.
These are user processes that were created with wf:async invocation. This processes was very useful to organize persistent stateful connection for legacy async technology like COMET for XHR channel. If you have problem with proxying WebSocket stream you can easily use XHR fallback that is provided by xhr.js N2O companion library. Async processes are optional and only needed when you have a UI event taking too much time to be processed, like gigabyte file uploads. You can create multiple async processes per user. Starting from N2O 2.9 all async processes are being created as gen_server under n2o_sup supervision tree.
In SPA mode N2O can serve no HTML at all. N2O elements are bound during initialization handshake and thus can be used regularly as in DSL mode.
In the example provided in n2o/samples you can find two different front end to the same review application which consist of two page modules index and login. You can access this application involving no HTML rendering by using static file serving that could be switched to direct nginx serving in production.
Or you can see DTL rendered HTML pages which resides at following address: