Reducing Frontend Complexity with Phoenix LiveView State Management

The API Overhead Problem

Modern web development often forces a strict separation between the frontend and backend. To build a simple real-time feature, developers typically build a REST or GraphQL API, define JSON schemas, manage a client-side state store (like Redux or Vuex), and handle asynchronous network requests. This creates a "double-implementation" burden where the same logic—validation, state transitions, and data formatting—must exist in both JavaScript and the backend language.

Phoenix LiveView solves this by shifting the state management back to the server. Instead of the client requesting data and deciding how to render it, the server maintains the state and pushes only the necessary HTML changes to the browser over a persistent WebSocket connection.

How Server-Side State Works

LiveView leverages Elixir's lightweight processes. Every user who connects to a LiveView page gets their own dedicated process on the server. This process holds the assigns—a map of data that represents the current state of the UI.

When a user interacts with the page (e.g., clicking a button), a small event is sent over the WebSocket. The server handles this event, updates the assigns, and calculates the difference between the old HTML and the new HTML. Only this "diff" is sent back to the browser, where a small JavaScript runtime patches the DOM. This eliminates the need to write custom API endpoints for every UI interaction.

Worked Example: A Real-Time Counter

To implement a stateful component, you define a module that implements the Phoenix.LiveView behavior. This requires two primary functions: mount/3 for initialization and handle_event/3 for interaction.

def module MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  # Initializes the state when the page loads
  def mount(_params, _session, socket) do
    {:ok, assign(socket, :count, 0)}
  end

  # Handles the 'increment' event from the client
  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, fn count -> count + 1 end)}
  end

  # Renders the HTML based on current assigns
  def render(assigns) do
    ~H"
    <div>
      <p>Current count: <%= @count %></p>
      <button phx-click="increment">Add 1</button>
    </div>
    "
  end
end

Execution Details:

• Where to run: This code lives in the lib/my_app_web/live/ directory of a Phoenix project.
• Permissions: Requires standard application execution permissions for the Elixir runtime.
• Expected Check: Open the browser's Network tab and filter by "WS" (WebSockets). When clicking the button, you should see a binary frame sent to the server and a small diff returned, rather than a full page reload or a JSON API response.

Trade-offs: Memory and Latency

While removing the API layer simplifies development, it introduces new architectural constraints. Because every connected user has a stateful process on the server, memory consumption scales linearly with the number of active users. A page with 10,000 concurrent users means 10,000 Elixir processes holding state in RAM.

Additionally, because every interaction requires a round-trip to the server, high-latency connections can make the UI feel sluggish. For interactions that require immediate feedback—such as a dropdown menu opening or a complex CSS animation—LiveView provides JS Hooks. These allow you to write small snippets of client-side JavaScript to handle purely visual changes without waiting for the server.

Verifying the Implementation

To verify that your LiveView is operating efficiently, check the following:

1. Diff Verification: Ensure that changing one value in assigns does not cause the entire page to re-render. Inspect the WebSocket frames to confirm only the changed HTML fragment is transmitted.
2. Process Monitoring: Use the Elixir :erlang.system_info(:process_count) command in the IEx shell to monitor how many processes are created as users connect.