24 ms·

What I don't understand with these technologies, is how you do continuous deployment without breaking all running client sessions evertime.

dnsbty 7y ago
With Erlang releases (compiled code with the Erlang runtime included) you can do hot code swapping to change the code while it’s still running. And iirc I believe LiveView will have all the state necessary client-side to be able to reconstruct the session when reconnecting the socket. I’m not near my development machine to make sure on that one though.
- out_of_protocol 7y ago
  As far as i know it doesn't work this way (session restoration) as of now. Something could be done but requires a lot of effort
- te_chris 7y ago
  We store our sessions in Redis and don't do hot code swapping but deploys do still mostly just work and live channels normally reconnect without any noticeable downtime. We run everything on GKE so a deploy is just rolling container swaps. Liveview is built on top of channels, so worth reading up about them: https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html
machiaweliczny 7y ago
I was just storing session state in Redis
josevalim 7y ago
LiveView does two things in particular: 1. It includes live navigation, which updates the URL as you interact with the app. For example, if you try the live scaffold generator in Phoenix v1.5.0-rc.0, you will see that once you click the "New Post" modal, the URL changes to "/posts/new". So if users reconnect by any reason (poor connection, new deployment, etc), they will go back to the same page with the same modal. 2. For forms, we automatically submit the current form state on reconnections, allowing the server and client to sync up. For complex applications, think a chat app or a game, then you have to persist messages, the game state, and what not on the server. But that would be necessary regardless if you are using LiveView or not.
- elcritch 7y ago
  I didn't realize that killing the LV server process would act just like a reconnect.. But that makes sense! It's been really impressive how well LV reconnects even when a server has been down for a while (I use RPi3's and they loose WiFi or reboot sometimes). It's good to note that using the live navigation you can pass parameters via the URL. That's my main method for graphing / data view pages.

dnsbty 7y ago

With Erlang releases (compiled code with the Erlang runtime included) you can do hot code swapping to change the code while it’s still running. And iirc I believe LiveView will have all the state necessary client-side to be able to reconstruct the session when reconnecting the socket. I’m not near my development machine to make sure on that one though.

out_of_protocol 7y ago
As far as i know it doesn't work this way (session restoration) as of now. Something could be done but requires a lot of effort
te_chris 7y ago
We store our sessions in Redis and don't do hot code swapping but deploys do still mostly just work and live channels normally reconnect without any noticeable downtime. We run everything on GKE so a deploy is just rolling container swaps. Liveview is built on top of channels, so worth reading up about them: https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html

machiaweliczny 7y ago

I was just storing session state in Redis

josevalim 7y ago

LiveView does two things in particular: 1. It includes live navigation, which updates the URL as you interact with the app. For example, if you try the live scaffold generator in Phoenix v1.5.0-rc.0, you will see that once you click the "New Post" modal, the URL changes to "/posts/new". So if users reconnect by any reason (poor connection, new deployment, etc), they will go back to the same page with the same modal. 2. For forms, we automatically submit the current form state on reconnections, allowing the server and client to sync up. For complex applications, think a chat app or a game, then you have to persist messages, the game state, and what not on the server. But that would be necessary regardless if you are using LiveView or not.

elcritch 7y ago
I didn't realize that killing the LV server process would act just like a reconnect.. But that makes sense! It's been really impressive how well LV reconnects even when a server has been down for a while (I use RPi3's and they loose WiFi or reboot sometimes). It's good to note that using the live navigation you can pass parameters via the URL. That's my main method for graphing / data view pages.