I’d rather say they build on top of each other. PubSub is just plain pubsub between elixir nodes, channels adds clients connecting to elixir nodes through various transports to the mix (by default long poll or websockets) and LV builds on top of channels to allow for dynamic html driven from the server.
Let’s start with the basics, you could use LiveView without PubSub. Phoenix has a dependency in the underlying channel in order to provide some convenience, but that’s not core to how LiveView/Channels work. Digging in:
On the surface LiveView lets you write (mostly) Elixir to build rich UIs. The messaging that happens back/forth to the frontend/backend is not tied to PubSub. For example, clicking a button will send a message from client->server but PubSub is not involved.
But LiveView isn’t just a library to let you build rich UIs in Elixir. It has a real-time component that lets you do things like update the UI based on a change that happened somewhere else. This is “magical” in some ways, but is critically backed by PubSub.
Let’s say that user A is connected to server 1. An event happens over a webhook and arrives on server 2. User A is not connected to server 2, so it wouldn’t get the real-time update and your UI is stale (not real-time).
This is where PubSub comes in. When the event happens on server 2, you can broadcast that event over PubSub. Other servers receive that event and they see that there’s a listener that cares about the event (your LiveView process). The event is processed and the UI is updated—your app is real-time.
Just to be clear though, that’s optional. If you just want the rich UI building and worry about real-time later, then you likely won’t even think about PubSub other than the setup instructions.
edit1: Added bit about how Phoenix has a dependency on PubSub, so it’s required to use LiveView. Added bit about how you don’t need to worry about PubSub unless you want real-time updates
PubSub is like, well, PubSub. It’s the Publish-Subscribe pattern. In JS I think there’s the EventBus thing which is similar?
Processes subscribe to a topic they are interested in, like "user:541:notifications"
A publisher is someone that sends a message to that topic, and what the PubSub server(a message bus) does is to relay the message to every process subscribed to that topic.
So, the publisher sends messages to the PubSub indicating the topic, and the PubSub takes care of figuring out who are the recipients and relays the message to them. The Publisher doesn’t need to know anything about the subcribers, it only sends messages to the PubSub server.
Channels and Liveview use this under the hood to relay messages to the right components. Channel topics in Phoenix are essentially PubSub topics.
Now Liveview is a complete different beast and it’s about building interactive user interfaces. It is built on top of Phoenix Channels, so by extension it also uses PubSub under the hood.
Because PubSub is a component implementing a pattern, you can use it for your own purposes, not only Liveview. That’s the example Steve was mentioning.
For a real world example you can check the LiveBeats app by Chris McCord. Here a liveview is subscribing to pubsub events:
And here are some functions that handle the messages coming through PubSub to update the UI or the liveview state: