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.
Popular in Questions
Other popular topics
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
- #javascript
- #code-sync
- #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
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









