All fair and true once I get there, but I really haven’t pieced together the most crucial part, which is what exactly the sequence of requests, calls, messages and events are that result in the web-socket (I hear I should actually say Channel as the abstraction of either a web-socket or a long-poll setup depending on what the client and the network between can handle) connecting the JS in the client and the process in the server pod where the state is presented as the socket parameter to a variety of callback functions and event handlers that returns a modified version of it. I recognise that as gen_server style behaviour so I’m not overly confused by state as a parameter, but if the fact that the app runs across multiple clusters is in play in any way, manually or automagically, I need to know about it as basis for everything else I figure on doing. It’s fine to say Elixir is designed to run on clusters and imply I shouldn’t overthink it and let the magic do its thing, but unfortunately that hadn’t worked out all that brilliantly for me of late so now I am compelled to figure out exactly what enables it. There ultimately has to be a difference between a single node BEAM and a cluster of BEAM nodes and part of my concern is the number of people calling BEAM clustering, being fully meshed, way too chatty, meaning network intensive, for its own good and certainly too much for WAN links to work.
I’m intent is to grow beyond a single cluster over WAN links so if I don’t know how the clustering gets involved if at all then I don’t stand a chance at all of keeping intra-cluster and inter-cluster comms separate, and that would be a costly mistake.
So, I have a proposal. Tell me if the following statements are 100% accurate and if not what adjustment they need to be accurate. Once we’ve agreed on what should be accurate, I shall go do my best to confirm that the behaviour I see matches that or bring you proof that it doesn’t.
- a LiveView page’s two renders does calls the same callbacks but as part of two very different algorithms.
- the two versions build the same data in memory independent of the other which means they can run on different nodes without any coordination of communication between the nodes.
- One of the processes dies as soon as the page content had been assembled and sent to the client despite being part of a LiveView setup.
- The other process, aware of its role in the LiveView life cycle keeps the socket open (perhaps without even sending the rendered data) and waits for the js on the client to upgrade the socket to a web-socket or engages long poll.
- once the socket is established the second version of the process listens for messages from the client in the socket, processes it using application callbacks to which it sends the assigns and other socket attributes derived during the duplicate startup processing as the socket parameter which serves as the state “variable”.
- When the network layer changes the state of the socket itself, either because the connection was reset or terminated from the client side, the socket handler either participates in an attempted reconnection or closes the socket as well and abandon the state it had kept in memory.
- When the js code detects a change in the socket state it attempts to reconnect, failing which it reports a problem and waits for the user to reload the page which re-initialises everything from scratch in a brand new session.
It remains to be seen if that is accurate or not, but if it is, and from where I’m sitting right now, it appears to have been a rather trivial exercise to avoid the double render and associated double data loading and processing. Especially if the second copy doesn’t really send through the initially rendered content but only the subsequent deltas calculated from that. If that turns out to be true I will go reread the rationale in the lifecycle descriptions another thousand times to figure out what I missed that made it a bad idea to do the hard work only once.
