MarthinL
Clustered LiveView app web socket
Pardon the dumb question, but when the LiveView JavaScript establishes its web socket (apparently by upgrading the regular HTTP GET request of the /live endpoint to a bi-directional TCP socket), how does data sent to the server via the socket reach the process holding the session state (assigns, etc.)?
It all works well. I am just confused by concrete evidence of the page request being served from one pod, but the LiveView socket connects to another pod in a cluster, i.e. two different BEAM instances on two different VM.
Most Liked
LostKobrakai
There is no shared state on the server between those requests. The only shared state is the session (cookie/encoded in the markup).
rhcarvalho
One thing to consider is that Elixir/Erlang/the BEAM natively supports clustering. Whether your multiple pods form a cluster from Elixir’s point of view depends on your configuration.
For the LiveView socket state, it is as you started your reasoning: client request reaches your Kubernetes ingress, eventually reaches a Bandit/Cowboy web server in one of the pods, the server returns the “disconnected” rendered HTML, the browser runs JS which connects the socket - it may land on any pod - the server upgrades the connection gets to a WebSocket and the LiveView process and state lives in this pod that served the second “connected” request.
If you have the BEAM setup as a cluster, then processes on different pods can communicate, and for example exchange messages through PubSub.
Hermanverschooten
The state of the initial mount is lost after the render completes, this is the same as a request to a controller. The js then initiates the new request which will become the websocket connection managed by the liveview process on the server. For recovery after a disconnect it will first build the initial state again in mount, then there is code that will resent the form content if any to update the state on the server.
Last Post!
MarthinL
Could be that, could be we haven’t had enough shared experiences for them to assign any weight to what I reported as actually happening in production clusters right now while they worry about what could happen in clusters when programmers don’t think. Been interesting though.
Thanks for engaging and encouraging me. Next time don’t just lurk on the sidelines, yank me out of the fire earlier, OK? 
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"