Posted inProgramming

Build Real-Time Apps with Phoenix LiveView: Server-Side State Without JavaScript

Programming tutorial - IT technology blog
Programming tutorial - IT technology blog

The Real-World Problem: The 2:14 AM Client-State Desync

Last month, an urgent PagerDuty alert woke me at 2:14 AM. Our warehouse inventory board was displaying phantom reservations. Two forklift operators had claimed pallet #PL-8492 at the exact same second. That glitch triggered two parallel loading tickets and choked bay door 4 for 45 minutes.

The backend logs told a surprising story. PostgreSQL row-level locks were solid. The REST endpoints showed 200 OK across the board.

The breakdown came from our 1.8 MB React bundle running on Zebra handheld scanners over spotty 2.4 GHz warehouse Wi-Fi. Three layers fought each other across tabs: Redux stores, custom WebSocket reconnect hooks, and optimistic UI mutations. As packets dropped, local browser memory drifted away from the database. We lost three hours untangling phantom race conditions that existed only inside the browser’s V8 engine.

Why Client-Side State Management Breaks Under Pressure

Pairing a client-side SPA framework (React, Vue, or Svelte) with a REST or WebSocket API forces you to solve distributed consensus inside an unreliable node: the end user’s browser.

1. Duplicated State Engines

You write validation rules and state transitions in backend business logic. Then you rewrite those exact models in TypeScript on the frontend so buttons toggle without latency. Network jitter guarantees those two implementations will eventually disagree.

2. A 9-Step Event Pipeline

Every shared interaction demands an exhausting chain: DOM listener → client dispatch → WebSocket transport → backend controller → database lock → PubSub broadcast → remote client listener → client store reducer → virtual DOM diff. Drop a single packet or mismanage an optimistic rollback, and your UI enters an invalid state.

3. Memory and Bundle Tax

Modern SPAs load hundreds of kilobytes of state synchronization libraries just to reconcile UI diffs. On low-powered rugged tablets or mobile devices, this overhead drains batteries and drops frames during critical warehouse shifts.

Solutions Compared: SPA vs. SSE/HTMX vs. Phoenix LiveView

During our post-incident review, we evaluated three architectures to prevent state desync permanently:

  • Approach A: Hardened React + Socket.io
    Requires monotonic sequence numbers on every JSON frame, explicit reconnect buffers, and complex optimistic rollback logic. It works, but it adds roughly 400 lines of brittle TypeScript per screen.
  • Approach B: HTMX with Server-Sent Events (SSE)
    Clean for read-heavy dashboards. However, bidirectional real-time workflows—like immediate multi-operator lockouts—require separate AJAX POST requests for every action, introducing perceptible round-trip latency.
  • Approach C: Phoenix LiveView on the BEAM
    The server runs an isolated, lightweight process (an Erlang/Elixir GenServer taking under 40 KB of RAM) for each connected client. The browser runs a tiny runtime (~35 KB gzipped). User inputs travel as compact binary messages over a persistent WebSocket, and the server replies with minute byte-level HTML diffs.

The Production Solution: Server-Driven State with LiveView

We migrated the pallet dispatch board to Phoenix LiveView. Our bundle dropped from 1.8 MB of JavaScript to under 45 KB total assets. Zero state lives in the browser, making desyncs structurally impossible.

Step 1: Create a Minimal Phoenix Project

Generate a clean Phoenix application with LiveView enabled:

# Install the Phoenix archive generator
mix archive.install hex phx_new 1.7.14

# Generate project without email or default analytics dashboards
mix phx.new warehouse_ops --no-mailer --no-dashboard
cd warehouse_ops
mix ecto.setup

Step 2: Build the Stateful LiveView Module

Save this module to lib/warehouse_ops_web/live/pallet_live.ex. State management, concurrency locks, and markup reside in a single place:

defmodule WarehouseOpsWeb.PalletLive do
  use WarehouseOpsWeb, :live_view

  @topic "warehouse_pallets"

  @impl true
  def mount(_params, _session, socket) do
    if connected?(socket) do
      Phoenix.PubSub.subscribe(WarehouseOps.PubSub, @topic)
    end

    initial_state = %{
      pallet_id: "PL-8492",
      assigned_to: nil,
      status: :available,
      units: 140
    }

    {:ok, assign(socket, pallet: initial_state)}
  end

  @impl true
  def handle_event("claim_pallet", %{"user" => user_name}, socket) do
    pallet = socket.assigns.pallet

    case pallet.status do
      :available ->
        updated_pallet = %{pallet | status: :claimed, assigned_to: user_name}
        Phoenix.PubSub.broadcast(WarehouseOps.PubSub, @topic, {:pallet_updated, updated_pallet})
        {:noreply, assign(socket, pallet: updated_pallet)}

      :claimed ->
        {:noreply, put_flash(socket, :error, "Pallet already claimed by #{pallet.assigned_to}")}
    end
  end

  @impl true
  def handle_info({:pallet_updated, updated_pallet}, socket) do
    {:noreply, assign(socket, pallet: updated_pallet)}
  end

  @impl true
  def render(assigns) do
    ~H"""
    <div class="p-6 max-w-lg mx-auto bg-slate-900 text-white rounded-xl shadow-md">
      <h1 class="text-2xl font-bold mb-4">Pallet Dispatch Tracker</h1>
      <div class="border border-slate-700 p-4 rounded-lg mb-4">
        <p><strong>ID:</strong> <%= @pallet.pallet_id %></p>
        <p><strong>Units:</strong> <%= @pallet.units %></p>
        <p><strong>Status:</strong>
          <span class={if @pallet.status == :available, do: "text-green-400", else: "text-amber-400"}>
            <%= String.upcase(to_string(@pallet.status)) %>
          </span>
        </p>
        <%= if @pallet.assigned_to do %>
          <p><strong>Claimed By:</strong> <%= @pallet.assigned_to %></p>
        <% end %>
      </div>

      <div class="flex gap-2">
        <button
          phx-click="claim_pallet"
          phx-value-user="Operator_A"
          disabled={@pallet.status != :available}
          class="bg-blue-600 hover:bg-blue-700 disabled:opacity-40 px-4 py-2 rounded font-semibold">
          Claim as Operator A
        </button>
        <button
          phx-click="claim_pallet"
          phx-value-user="Operator_B"
          disabled={@pallet.status != :available}
          class="bg-emerald-600 hover:bg-emerald-700 disabled:opacity-40 px-4 py-2 rounded font-semibold">
          Claim as Operator B
        </button>
      </div>
    </div>
    """
  end
end

Step 3: Wire the Endpoint

Mount the live component in lib/warehouse_ops_web/router.ex:

scope "/", WarehouseOpsWeb do
  pipe_through :browser

  live "/pallets", PalletLive
end

What Happens During a Click

  1. Micro-Payloads: When an operator clicks Claim, the client sends a binary WebSocket packet measuring under 90 bytes to the server-side GenServer.
  2. Server-Side Authority: handle_event/3 checks the current state in memory. If Operator A clicked first by 4 milliseconds, Operator B’s click hits the :claimed branch and receives a flash alert without altering records.
  3. Diff-Only Wire Updates: LiveView parses template dynamics against its previous render tree. It skips the static HTML entirely, sending back a JSON diff containing only the changed keys (roughly 38 bytes).
  4. Automatic Broadcasts: Through Phoenix.PubSub, the server pushes the update to all connected devices in under 2 milliseconds across the local network.

Reclaim Your Nights

Moving state from fragile browser caches back to an Elixir GenServer eliminates an entire taxonomy of client-side race conditions. You write straightforward server-side code, slash JavaScript payloads by up to 95%, and stop answering emergency operational pages at 2:00 AM.

Share:
Tags: