Phoenix Framework Overview

Phoenix is the dominant web framework for Elixir, in roughly the same role Rails holds for Ruby or Django holds for Python. It's built directly on top of everything covered in the Concurrency & OTP section — that's not incidental, it's the reason Phoenix performs the way it does.

Why Elixir for web backends

A typical web server handling many simultaneous requests needs some way to isolate them from each other. Phoenix (via the Plug and Cowboy/Bandit layers underneath it) spawns a lightweight BEAM process per connection — the same kind of process you saw in the Concurrency & OTP lessons. Because those processes cost only a few kilobytes each and are scheduled fairly by the BEAM, a single Phoenix server can hold open tens or hundreds of thousands of concurrent connections without the heavyweight thread-per-request overhead that limits many other backend stacks. This is precisely why Elixir gets chosen for chat platforms, real-time dashboards, and anything defined by "a huge number of clients connected at once."

The request pipeline

Phoenix organizes request handling into plugs — small, composable units that transform a connection:

defmodule MyAppWeb.Router do
  use MyAppWeb, :router

  pipeline :api do
    plug :accepts, ["json"]
  end

  scope "/api", MyAppWeb do
    pipe_through :api
    get "/users/:id", UserController, :show
  end
end

defmodule MyAppWeb.UserController do
  use MyAppWeb, :controller

  def show(conn, %{"id" => id}) do
    user = MyApp.Accounts.get_user!(id)
    json(conn, %{id: user.id, name: user.name})
  end
end

If you've used another MVC-style web framework, this structure — router, pipeline, controller — will feel immediately familiar. What's different is everything happening underneath it: each request runs in its own isolated, supervised process.

Channels: real-time, bidirectional communication

Channels give Phoenix persistent, two-way communication over WebSockets, built directly on the process model:

defmodule MyAppWeb.RoomChannel do
  use MyAppWeb, :channel

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

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

Every connected client gets its own process managing that socket, and broadcast!/3 fans a message out to every subscriber — the same message-passing model from earlier lessons, just applied to WebSocket clients instead of internal processes. This is the foundation for chat apps, live notifications, and multiplayer features.

LiveView: rich UI without hand-written JavaScript

Phoenix LiveView goes a step further: it renders and updates interactive UI over a persistent WebSocket connection, keeping the actual state on the server rather than shipping a client-side JavaScript framework.

defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  def render(assigns) do
    ~H"""
    <button phx-click="increment">Count: <%= @count %></button>
    """
  end
end

When the button is clicked, the click is sent over the socket to the server, handle_event/3 updates state, and Phoenix sends back just the minimal HTML diff needed to update the page — no full page reload, and critically, no hand-written JavaScript for this interactivity. Each LiveView is backed by its own supervised BEAM process, so a crash in one user's LiveView doesn't affect anyone else's session.

Why this matters for choosing a backend

Compared to a typical request/response backend bolted onto a separate client-side framework for real-time features, Phoenix collapses that into one language, one mental model, and one deployment: the same process-per-connection architecture handles plain HTTP requests, WebSocket channels, and full LiveView UIs. For anything where "many users, connected concurrently, needing live updates" is the core requirement — collaborative tools, dashboards, chat, live scores — Phoenix is one of the strongest choices in the backend framework landscape today, precisely because of the concurrency model this entire course has been building toward.