A LiveView is a Course of · Fly
We’re Fly.io. We run apps for our customers on {hardware} we host around the globe. This publish is about Elixir Course of and the way they work as Phoenix LivViews. Fly.io occurs to be a terrific place to run Phoenix functions. Try how you can get started!
LiveView lets customers rise up to hurry rapidly by being straightforward to study, particularly with the acquainted mount, render and occasion handler system that React builders will instantly acknowledge. However LiveView differs from different front-end frameworks in a single very consequential method:
A LiveView is a course of.
And regardless that the LiveView docs immediately name out that reality:
A LiveView is a course of that receives occasions, updates its state, and render updates to a web page as diffs.
This reality units LiveView aside from nearly each different front-end framework and is so vital that I feel it may use somewhat reiteration.
Elixir has Processes
In Elixir and Erlang, ‘processes’ do not refer to operating system processes or threads. They are what’s sometimes called green threads or actors. On a single core CPU they run concurrently and are scheduled and managed by the Erlang Digital Machine; on a number of cores they run in parallel. Every course of in Elixir and Erlang wants ~300 phrases of reminiscence, and takes microseconds to start out, so they’re extremely low cost. Within the Erlang Digital Machine, every part that executes code is operating in a course of.
I extremely advocate you try this excellent guide from the Elixir web site that goes into among the particulars about processes. We’ll hold it barely increased degree right here.
Every Course of can execute code, it has a first-in-first-out mailbox that any different course of can ship messages to, and it could possibly additionally ship messages. Every course of is sequential, that means it could possibly solely deal with one message at a time. The Erlang VM operates sort of like an Working System scheduler, the place it could possibly begin and pause or “preempt” work every time it desires. Whereas it’s ready for a message, your course of is totally ignored by the scheduler and does not dissipate treasured assets.
Once we work with GenServers, that are increased degree abstractions on prime of processes, our movement appears to be like sort of like this:
A course of begins and units its preliminary state, then it waits for a message. When it receives a message it handles it, will get a brand new state and returns to ready. This is a vital factor to grasp: a course of is barely in a position to execute if it receives a message. When it’s began or initialized a course of executes some code, then it waits for a message. This implies an idle course of will not eat assets. There are additionally some messages which can be dealt with internally by GenServers for you, however that is outdoors the scope for this publish.
Since a person course of is sequential, if the message dealing with operate takes a very long time to execute, the mailbox or queue could again up. If the method is just not anticipating a ton of recent messages this may be okay. Whereas utilizing a Process it’s okay to do a expensive calculation as a result of these processes do not anticipate extra messages. Whereas within the case of a LiveView course of, a person will see a web page that is unable to answer occasions or render updates, that is unhealthy.
The LiveView Process
Just like any other process, LiveView follows a specific lifecycle. Here’s a simplified flow chart to illustrate this:
Where assigns is our state and event is a special case of a message we make special callbacks for. Every user event or params event is a message being handled by our callbacks. So let’s think through some of the implications of this.
Every user has their own Process.
Despite each user having their own process, it’s not an issue due to the lightweight nature of these processes. The benefits we gain in terms of performance and scalability make it well worth it. To be clear: if you do a normal HTTP request using Phoenix controllers that connection gets its own Process too, it just is immediately killed once you’ve sent the response and closed it. In LiveView we keep that process alive.
LiveView lifecycle functions need to respond quickly.
Every message is handled sequentially, meaning we need to make sure that handle_event, mount, handle_params, and handle_info functions return quickly since they could be blocking a user interaction.
If you have some slow job, query or calculation you should use the built-in async primitives, such as Tasks. Berenice wrote an excellent post showing an example of doing that just in her recent Async Processing in LiveView publish.
Be careful of what you put into assigns.
Assigns are kept for the entire lifetime of the page for every user, and you can quickly chew up memory by shoving a ton of stuff into it. It is okay to re-query stuff you need, and look into using streams when you will have an extended listing of things.
Wrap up
In conclusion, the process is the heart of the Erlang VM, making programming in Elixir a uniquely fast, resilient, and special experience. On purpose, this is only scratching the surface of what a Process is because if the Phoenix team is doing their job right, you shouldn’t need to know much more to be productive and effective at building scalable applications.
When you are ready to learn more, here are two great resources:
Fly.io is a great way to run your Phoenix LiveView app close to your users. It’s really easy to get started. You can be running in minutes.
