Phoenix: Channels, PubSub & the BEAM Advantage

Channels: Real-Time Beyond LiveView

defmodule MyAppWeb.RoomChannel do
  use MyAppWeb, :channel

  def join("room:lobby", _params, socket) do
    {:ok, socket}
  end

  def handle_in("new_msg", %{"body" => body}, socket) do
    broadcast!(socket, "new_msg", %{body: body})
    {:noreply, socket}
  end
end

// Topic-based, bidirectional real-time communication over
// WebSockets -- the foundation LiveView itself builds on

PubSub Across a Cluster

Phoenix.PubSub provides the broadcast mechanism Channels (and LiveView) use to publish messages to subscribers -- designed to work across a distributed cluster of nodes, not just a single server process.

Why BEAM Handles Many Connections Well

BEAM processes are extremely lightweight compared to OS threads, so a Phoenix app can maintain a very large number of simultaneous WebSocket connections, each backed by its own isolated process, without thread-per-connection overhead.

"Let It Crash"

Rather than defensively coding against every possible failure, a process is allowed to crash and be automatically restarted by a supervisor in a clean state -- isolating failures instead of letting them cascade or leave inconsistent state.

Phoenix Without LiveView

Phoenix's productivity-focused conventions (routing, contexts, Ecto integration) and BEAM's concurrency/fault-tolerance benefits are valuable independent of whether LiveView is used at all -- a solid choice for a conventional JSON API too.