Server-Sent Events in Practice

The plain-language idea

The previous lesson covered the real implementation work a WebSocket needs from the client: opening it inside a component's lifecycle, closing it correctly, and hand-rolling reconnection with backoff. Server-Sent Events (SSE) are the concrete implementation counterpart for the one-directional case — server pushes to client, client never sends anything back over that same channel — and the client-side API involved is EventSource.

Using it is genuinely simple:

• Create an EventSource pointed at a streaming endpoint.
• Listen for the default message event, or for named custom event types if the server sends them.
• Get automatic reconnection for free. If the connection drops, the browser's own EventSource implementation retries it on its own — no manual close-detection, no backoff loop to write, none of the reconnection code the WebSocket lesson walked through by hand.

That last point is the real, practical payoff of SSE over a hand-rolled WebSocket for this specific shape of problem: reconnection is simpler because it isn't your code's job.

See it in a real thing: a live notifications feed

function useNotifications() {
  const [notifications, setNotifications] = useState<Notification[]>([]);
  const [connectionState, setConnectionState] = useState<"connecting" | "open" | "retrying">("connecting");

  useEffect(() => {
    const source = new EventSource("/api/notifications/stream");

    source.onopen = () => setConnectionState("open");

    // The default, unnamed event type.
    source.onmessage = (event) => {
      const notification: Notification = JSON.parse(event.data);
      setNotifications((prev) => [...prev, notification]);
    };

    // A named custom event the server can send alongside plain messages.
    source.addEventListener("alert", (event) => {
      const alert = JSON.parse((event as MessageEvent).data);
      setNotifications((prev) => [...prev, { ...alert, urgent: true }]);
    });

    source.onerror = () => {
      // The browser is already retrying the connection at this point —
      // this handler exists purely to reflect that state in the UI.
      setConnectionState("retrying");
    };

    return () => source.close();
  }, []);

  return { notifications, connectionState };
}

Even though reconnection happens without any code from you, the error event is still worth listening for. A connection that silently retries with zero UI feedback looks broken to a user during a real outage — they see updates stop arriving with no explanation. Surfacing a "reconnecting" state turns invisible automatic recovery into something the UI can actually communicate.

What people usually miss

Watch out

• SSE is one-directional, and that's a hard limit, not a rough edge. If the client ever needs to send data back over the same channel it's receiving updates on, EventSource genuinely cannot do it — that's the point where a WebSocket, not SSE, is the correct tool.
• SSE is text-based, specifically UTF-8, with no binary support. A feed that needs to push binary data isn't a fit for SSE at all, independent of the directionality question.
• "Automatic reconnection" doesn't mean "invisible to the user." The browser retrying on its own is a real implementation win, but a UI that gives no feedback during a real outage still reads as broken, even though the underlying connection is quietly recovering.
• Named events aren't optional metadata — they change what handler runs. A server sending an alert event that the client only listens for as message (the default) will silently never trigger the alert handler, because addEventListener("message", ...) and onmessage only catch the unnamed default event type.

Why this matters in interviews

"Would you use SSE or a WebSocket here?" is a common follow-up once a real-time feature comes up, and the strongest answers name the concrete implementation trade directly: SSE's reconnection is simpler because the browser handles it, but that's only available because the problem is one-directional in the first place.