I’ve been using Elixir/Phoenix for nearly 3 years, so I’m pretty familiar with Channels and the way they work, but I have very little knowledge of LiveView, besides a quick look at some demos. I’m trying to understand exactly how they’re similar and how they differ.
Let’s take for example a Slack-like app. With channels we would grab the last N messages, render the page, setup some code to listen to form submissions, after which we send the new message to the backend, which stores it, then sends the message to anyone listening on the same topic, some JS appends the message to the DOM. The channel really just holds the state of the sockets of the listeners on the topic, so it scales pretty well.
From what I seen in LiveView, the server is holding a lot more state right? So a user joins the chat, we look up the lasts N messages, we spin up a genserver to hold this state, and sync data between the client/server. As a new message is submitted, it gets added to each user’s state any synced.
Is my understanding correct? If I had 100 users on the same topic, would that be 100 genservers, each holding N messages (+ additional messages since the user joined) each? Or does the state get shared? If so, isn’t this much less scalable than channels?
2 Likes
I’m not an expert and haven’t used any of both on production. However, I’ve read a lot and played a bit. I think you are right - there should be 100 GenServers holding the state for each client. I can’t think of how that could work unless that’s the case.
The benefit of LiveView being that you don’t have to manage the state through JS. i.e. you have a single place to manage the HTML generation/state, and that’s the server.
I guess LveView isn’t here to replace Channels but rather facilitate a number of different cases. Autocomplete, form-validation and interaction, etc. I’d say that if you are building a comprehensive chat app, let’s imagine Slack; you will have to reach out to JS and Channels. At the same time, LiveView could be more than enough in the case of a one-on-one support chat bubble or something like that.
1 Like
Hi @pejrich I believe there are some misunderstandings here.
This is literally the same as channels. Phoenix live view is built on channels.
This is not correct. There is 1 channel process per client, not one global “channel” process for the whole topic. Ironically, the 1 process per client is exactly why live view and channels do scale so well. You avoid bottlenecking through a single process.
Now with respect to holding on to messages as your specific example, this is a good example of when to use Phoenix.LiveView — Phoenix LiveView v0.20.2 so that the total set of messages does not need to be kept in the browser state.
2 Likes
