Erlang Processes

Reduced Latency

The secret to reducing latency is simple. We try to deliver rendered HTML as soon as possible and render JavaScript only when WebSocket initialization is complete. It takes three steps and three Erlang processes for doing that.

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.

Page Serving Process

This processes are applicable only to the case when you serving not static HTML, but dynamically rendered pages with NITRO, DTL or ET template engines. The very first HTTP handler only renders HTML. During page initialization function Module:main/0 is called. This function should return raw HTML or NITRO elements that could be rendered into raw HTML. All created on the way JavaScript actions are stored in the transition process.

main() -> #dtl { file = "login", app = review, bindings = [ { body, #button { id = send, postback = chat } } ] }.

HTTP handler will die immediately after returning HTML. Transition process stores actions and waits for a request from a WebSocket handler.

Transition Process

Right after receiving HTML the browser initiates WebSocket connection thus starting WebSocket handler on the server. After responding with JavaScript actions the Transition process dies and the only process left running is WebSocket handler. At this point initialization phase is complete.

transition(Actions) -> receive {'N2O',Pid} -> Pid ! Actions end.

Transition process is only applicable to dynamically rendered pages served by n2o_document endpoint. You never deal with it manually.

Events Process

After that all client/server communication is performed over WebSocket channel. All events coming from the browser are handled by N2O, which renders elements to HTML and actions to JavaScript. Each user at any time has only one WebSocket process per connection.

event(init) -> wf:reg(room); event(chat) -> #insert_top(history,#span{body="message"}), wf:flush(room).

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.

Async Processes

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.

event(init) -> wf:reg(room), wf:async("looper", fun async/1); async(init) -> ok; aynsc(Chat) -> io:format("Chat: ~p~n",[Chat]).

SPA Mode

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.

open http://localhost:8000/static/app/login.htm

Or you can see DTL rendered HTML pages which resides at following address:

open http://localhost:8000/login.htm


Events | Privacy Policy | Feedback | Brandbook
Copyright © 2005–2016 Synrc Research Center s.r.o.