4 ms·

Can a LiveView process migrate to a different machine/VM? For example, there's a scheduled maintenance and I need to shut down one of the machines/containers. T

by kgeist 3y ago

Can a LiveView process migrate to a different machine/VM? For example, there's a scheduled maintenance and I need to shut down one of the machines/containers. The main advantage of stateless architectures for me is that state is not bound to a specific machine -- so you can easily add/remove machines, state is not lost if application dies, etc.

sodapopcan 3y ago
Not without doing that work yourself, no. I take a more classic web approach to LiveView which is to say I persist any important state right away. Like any multiple-step forms I would never store in server state, I'd persist each step. Of course that doesn't help if someone is halfway through filling out a form. If the socket disconnects then re-connects then you don't lose your work but not if you do a restart. I do wish there was a built-in way to store state on the client until it's submitted, we may get there, though! The true value of LiveView for me is the simplicity of not having to write yourself a web API to interact with your own backend as well as the dead simple real-time features. If you don't need the latter, that's fine, but having worked on collaborative apps that was a giant pain is what led me to LiveView.
jeremyjh 3y ago
No, and while there is a capability to hot reload releases (so that you could preserve state while deploying an update, for example), in practice almost no uses it because it is complicated. In practice, if you care about this aspect of user experience you may have to take some reasonably small steps to preserve state information in the client. Form state gets preserved automatically for most purposes, though there may be some forms that need to implement a call-back to preserve state, as explained in the docs: https://hexdocs.pm/phoenix_live_view/form-bindings.html#recovery-following-crashes-or-disconnects https://hexdocs.pm/phoenix_live_view/form-bindings.html#reco...
- throwawaymaths 3y ago
  I think liveview live reload uses hot reloading, so that's definitely a very nice ergonomic improvement that basically everyone uses all the time
  - jeremyjh 3y ago
    No, the dev tool works differently, it does not use the OTP release feature I’m talking about. If you hot upgrade stateful modules you have to supply migration functions when the structure changes. https://www.erlang.org/doc/design_principles/release_handling.html https://www.erlang.org/doc/design_principles/release_handlin...
pythonaut_16 3y ago
My recollection of the details is fuzzy, but I think a common solution to this is connection draining. You set up your deploy to bring up the new instance and direct all new traffic to that one and then hold the old one open until all sessions/connections end. Can't remember if/how that routing was accomplished in the BEAM (Erlang/Elixir VM). It's definitely possible but you might have to implement it yourself.
mikl 3y ago
In general, LiveView applications are built so they can be safely reloaded without significant data loss, according to the Erlang/Elixir “Let it crash”-philosophy. Besides scheduled maintenance, there’s all sorts of reasons why this might be needed: The user’s log-in expires, network issues, browser crashes, server hardware issues, deployment of a new version of your app… “Hot upgrades” can be implemented if you wish to, but often this is just handled by asking the client to reload the page, establishing a new connection, because any data or preferences have been persisted.
throwawaymaths 3y ago
Can a LiveView process migrate to a different machine/VM? Liveview makes no assumptions about the client connection or even stickiness of client to nodes in a cluster. If you store critical data in the liveview you could be in for some trouble. Always store important stuff into a recoverable, network aware datastore. The nice thing is that liveview is designed to be tolerant to client or client connection failures, you should design to be able to repopulate state sanely in the on_mount call. While this sounds bad, think of it as isolating the client connection failure domain from the data failure domain, so you should organize your code in those domains respectively If you want some sort of ephermal network state that lives on one node and not the database only (e.g. a game), the liveview should connect into that. If you want to store that in a genserver, a strategy like this is doable: https://youtu.be/nLApFANtkHs https://youtu.be/nLApFANtkHs
notpublic 3y ago
This video may be of interest to you: https://youtu.be/pQ0CvjAJXz4?t=1992 https://youtu.be/pQ0CvjAJXz4?t=1992 Bryan Hunter explains how they do it at HCA healthcare (not specifically LiveView process, but processes in general).

by kgeist 3y ago

sodapopcan 3y ago

Not without doing that work yourself, no. I take a more classic web approach to LiveView which is to say I persist any important state right away. Like any multiple-step forms I would never store in server state, I'd persist each step. Of course that doesn't help if someone is halfway through filling out a form. If the socket disconnects then re-connects then you don't lose your work but not if you do a restart. I do wish there was a built-in way to store state on the client until it's submitted, we may get there, though! The true value of LiveView for me is the simplicity of not having to write yourself a web API to interact with your own backend as well as the dead simple real-time features. If you don't need the latter, that's fine, but having worked on collaborative apps that was a giant pain is what led me to LiveView.

jeremyjh 3y ago

No, and while there is a capability to hot reload releases (so that you could preserve state while deploying an update, for example), in practice almost no uses it because it is complicated. In practice, if you care about this aspect of user experience you may have to take some reasonably small steps to preserve state information in the client. Form state gets preserved automatically for most purposes, though there may be some forms that need to implement a call-back to preserve state, as explained in the docs: https://hexdocs.pm/phoenix_live_view/form-bindings.html#recovery-following-crashes-or-disconnects https://hexdocs.pm/phoenix_live_view/form-bindings.html#reco...

throwawaymaths 3y ago
I think liveview live reload uses hot reloading, so that's definitely a very nice ergonomic improvement that basically everyone uses all the time
- jeremyjh 3y ago
  No, the dev tool works differently, it does not use the OTP release feature I’m talking about. If you hot upgrade stateful modules you have to supply migration functions when the structure changes. https://www.erlang.org/doc/design_principles/release_handling.html https://www.erlang.org/doc/design_principles/release_handlin...

pythonaut_16 3y ago

My recollection of the details is fuzzy, but I think a common solution to this is connection draining. You set up your deploy to bring up the new instance and direct all new traffic to that one and then hold the old one open until all sessions/connections end. Can't remember if/how that routing was accomplished in the BEAM (Erlang/Elixir VM). It's definitely possible but you might have to implement it yourself.

mikl 3y ago

In general, LiveView applications are built so they can be safely reloaded without significant data loss, according to the Erlang/Elixir “Let it crash”-philosophy. Besides scheduled maintenance, there’s all sorts of reasons why this might be needed: The user’s log-in expires, network issues, browser crashes, server hardware issues, deployment of a new version of your app… “Hot upgrades” can be implemented if you wish to, but often this is just handled by asking the client to reload the page, establishing a new connection, because any data or preferences have been persisted.

throwawaymaths 3y ago

Can a LiveView process migrate to a different machine/VM? Liveview makes no assumptions about the client connection or even stickiness of client to nodes in a cluster. If you store critical data in the liveview you could be in for some trouble. Always store important stuff into a recoverable, network aware datastore. The nice thing is that liveview is designed to be tolerant to client or client connection failures, you should design to be able to repopulate state sanely in the on_mount call. While this sounds bad, think of it as isolating the client connection failure domain from the data failure domain, so you should organize your code in those domains respectively If you want some sort of ephermal network state that lives on one node and not the database only (e.g. a game), the liveview should connect into that. If you want to store that in a genserver, a strategy like this is doable: https://youtu.be/nLApFANtkHs https://youtu.be/nLApFANtkHs

notpublic 3y ago

This video may be of interest to you: https://youtu.be/pQ0CvjAJXz4?t=1992 https://youtu.be/pQ0CvjAJXz4?t=1992 Bryan Hunter explains how they do it at HCA healthcare (not specifically LiveView process, but processes in general).