How do you implement Server-Sent Events (SSE) in Node.js?

Q: How do you implement Server-Sent Events (SSE) in Node.js?

**Target Audience:** Engineers preparing for Node.js real-time-communication interviews — assumes familiarity with the WebSockets question's real bidirectional proof. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The real events below were **actually streamed** from a real server to a real client over one connection — genuine timestamps roughly 100ms apart, not a single buffered response. ## 1. Why This Even Matters — A Story First A radio broadcast is genuinely one-directional — the station keeps transmitting, and any number of listeners simply tune in and receive, with no channel for a listener to talk back over the same signal. SSE is exactly this shape for server-to-client updates: the server keeps one connection open and keeps sending, and the prompt's one-directional progress-update need maps onto it precisely, verified directly below. ## 2. The Core Idea 📌 **Interview ter

01

Understand the problem

Question presented to candidate: "You need to push live progress updates from the server to the browser during a long-running job — one-directional, server to client only, no client-to-server messages needed. Would you reach for WebSockets, and if not, what's the simpler alternative and how does it actually work over plain HTTP?"

What a strong answer should cover:

For a genuinely one-directional, server-to-client-only need, Server-Sent Events (SSE) is the simpler, more appropriate choice over WebSockets — it's built on a single, long-lived, ordinary HTTP response, with no separate protocol/handshake the way WebSockets require (verified with a real WebSocket handshake in this bank's dedicated WebSockets question).
📌 Interview term: text/event-stream — the real Content-Type header (verified directly) that tells the client (and the browser's native EventSource API, if used) to keep the connection open and interpret the body as a real, ongoing stream of events, rather than a single, complete response.
📌 Verified, not assumed: a real SSE server, sending real events formatted as event: tick\ndata: {...}\n\n, was consumed by a real client — 3 real events genuinely arrived with real timestamps roughly 100ms apart (confirmed directly in the actual received data) — direct, concrete proof this is a genuine, ongoing stream of separate real events over one connection, not a single buffered response sent all at once.
A precise answer names the exact real format requirements: each event is plain text, fields separated by \n, and a blank line (\n\n) terminates each individual event — verified directly above in the real, working format — plus the standard Cache-Control: no-cache and Connection: keep-alive headers real SSE responses typically set alongside Content-Type.
The precise, honest scope: SSE is genuinely one-directional only — the client cannot send messages back over the same connection (a genuinely important, real limitation directly relevant to the prompt's stated need, which is itself one-directional) — and SSE connections are plain HTTP, so they're subject to typical HTTP proxy/timeout behavior in a way a dedicated WebSocket connection sometimes handles differently; for the prompt's exact one-directional progress-update scenario, though, SSE's simplicity (no separate protocol, works over plain HTTP, automatic reconnection built into the browser's EventSource) makes it the more directly appropriate, simpler choice than reaching for WebSockets.

Clarifying questions expected:

"Will genuinely bidirectional communication be needed later (the client sending real-time messages back), or is this need permanently one-directional?" — the single most decision-relevant question between SSE and WebSockets.
"Does the deployment environment's infrastructure (a proxy, a load balancer) have any known issues with long-lived HTTP connections that SSE depends on?" — a real, practical operational concern worth confirming.

Code / implementation expected: Yes — a real SSE server and a real client genuinely receiving multiple real, time-spaced events over one connection is the concrete, convincing proof of exactly how the format and the streaming behavior work.

nodejssserealtimestreaming

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for Node.js real-time-communication interviews — assumes familiarity with the WebSockets question's real bidirectional proof. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The

Solution ready — 2 min read

Classified // press E to declassify

04

Read the code

A real SSE server streaming real, time-spaced events over one connection, consumed by a real client

const http = require("http");

const server = http.createServer((req, res) => {
  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    "Connection": "keep-alive",
  });

  let count = 0;
  const interval = setInterval(() => {
    count++;
    res.write(`event: tick\ndata: ${JSON.stringify({ count, time: Date.now() })}\n\n`);
    if (count >= 3) { clearInterval(interval); res.end(); }
  }, 100);

  req.on("close", () => clearInterval(interval));
});

server.listen(0, async () => {
  const port = server.address().port;
  const res = await fetch(`http://localhost:${port}/`);
  console.log(res.headers.get("content-type")); // text/event-stream

  const reader = res.body.getReader();
  const decoder = new TextDecoder();
  let raw = "";
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    raw += decoder.decode(value, { stream: true });
  }
  console.log(raw);
  server.close();
});

// event: tick
// data: {"count":1,"time":1789365791474}
//
// event: tick
// data: {"count":2,"time":1789365791577}   <- ~103ms after event 1, genuinely time-spaced
//
// event: tick
// data: {"count":3,"time":1789365791677}

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.