skip to content

What does Server-Sent Events define for you that a WebSocket connection leaves you to build, and what can it never do?

level: juniorimportance: must knowfreq 78%

answer

  1. one direction, or both
  2. who defines the re-open
  3. ordinary response versus opaque bytes
  4. upstream needs its own request
  5. resumption from the last event id

basics

~20 s

Server-Sent Events defines automatic reconnection and a text event grammar over one ordinary HTTP response; a WebSocket connection defines neither, so you build them. The stream is server-to-client only, so anything the client sends needs a separate request.

solid answer

~50 s

Server-Sent Events is one ordinary `GET` whose response never ends: the server answers `200 OK` with `Content-Type: text/event-stream` and keeps writing `data`, `event` and `id` lines. Because it is still HTTP, you get two things defined for you — a conforming client re-opens the stream by itself after a drop, and it hands back the last event `id` it saw so a server that keeps a short history can fill the gap. What you can never do is send anything up that response: it flows server to client only, and a client message is a separate HTTP request. A WebSocket connection carries messages both ways, text or binary, but the specification tells you how a connection closes, not how a new one is opened in its place — reconnection, resumption and replay are your code.

code

http · 11 lines
http
GET /board/stream HTTP/1.1
Host: lifts.example
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

event: lift
id: 4812
data: {"lift":"gondola-1","state":"hold","waitMinutes":12}

go deeper

for a junior

Recall the one-line difference: an event stream flows server to client only and re-opens itself; a socket carries both directions and re-opens only if you wrote that code.

for a middle

Explain what each specification actually defines — a text event grammar, a server-set reconnect delay and resumption from the last event id on one side; messages in both directions and no replacement-connection policy on the other.

for a senior

Show that you priced the choice: what upstream traffic really exists and at what rate, what you would have to build on a socket to match free re-opening, and what staying inside ordinary HTTP buys in the path.

for a principal

Frame it as a cost you own for years. A second live transport means a second authorization story, a second reconnect implementation and a second capacity model in every product that adopts it.

## Two protocols, two different bargains **Server-Sent Events** is not a new protocol. The client issues an ordinary `GET`, asks for `text/event-stream` in `Accept`, and the server answers `200 OK` with `Content-Type: text/event-stream` and then simply never finishes the body. It writes lines — `data`, optionally `event` to name the kind of event and `id` to label it — and a blank line dispatches each event to the receiving application. No new port, no new scheme, no negotiation beyond content type. A **WebSocket** connection begins as an HTTP request too, but that request asks to leave HTTP behind. Once the connection is upgraded, what travels on it is no longer requests and responses but messages either side may write at any moment, framed by the WebSocket specification. That single structural difference produces two distinct bargains, and an interviewer is checking whether you can state both rather than reciting a preference. ## What Server-Sent Events hands you - **One direction, and only one.** The server writes; the client reads. There is no upstream channel on that response, at all. - **Reconnection.** A conforming client re-opens the stream on its own after the connection drops, waiting a delay the server can set with the `retry` field. No application code is in that path. - **Resumption.** Events may carry `id`, and the client presents the last one it saw on the re-open via `Last-Event-ID`, so a server that keeps a short history can replay the gap. - **A text grammar.** The body is UTF-8 text, so binary payloads must be encoded before they can go into `data`. - **An ordinary response.** Any HTTP client that reads a body incrementally can consume it, and everything in the path between the two ends treats it as a response — because it is one. ## What a WebSocket connection hands you - **Both directions, any time.** Either end may write without being asked, which is the whole point of the upgrade. - **Text or binary messages**, with no encoding tax on binary payloads. - **No opinion about re-opening.** The specification defines how a connection is closed and with what status; it does not define how a replacement connection is established, how far back to resume, or what to replay. Those are yours to design and maintain. - **No per-request identity after the open.** Authorization happens once, when the connection is established, and staying correct after that is application work. ## The comparison in one table | Axis | Server-Sent Events | WebSocket | |---|---|---| | Direction | server to client only | both, at any moment | | Reconnect | defined by the protocol | your code | | Resume after a gap | last event `id`, if the server keeps history | your cursor, your buffer | | Payload | UTF-8 text | text or binary | | Seen by the path | an ordinary HTTP response | opaque bytes after the upgrade | | Per-message overhead | field names and line breaks | a small binary header | ## Choosing, in the order the questions actually matter 1. **Does anything flow upstream at all?** If the honest answer is no — a status board, a feed, job progress, incrementally produced output — the one-way stream is the smaller system. 2. **If something does, at what rate and under what latency budget?** Occasional messages ride perfectly well as separate requests; continuous ones do not. 3. **Is the payload binary, in volume?** Text-only means encoding, and encoding means roughly a third more bytes plus the work on both ends. 4. **What would you have to build to match free re-opening?** Price that honestly before you call the socket "more flexible". ## When a duplex socket genuinely wins - Interactive upstream traffic: editing, input, drag positions, per-frame telemetry — anything where a full request round trip per message is the latency budget. - Binary payloads at volume, where the encoding tax is real money. - Symmetric peers, where both ends initiate and the model of "request" and "response" stops describing the conversation. - An application-level subprotocol both ends already speak over a socket. ## The two ways to get this wrong Reaching for the socket because a brief said "live" is the common one: you inherit reconnection, resumption and credential expiry as your own code in every product that does it, in exchange for a direction nothing ever used. The rarer mistake is the mirror image — insisting on a one-way stream when upstream traffic is continuous, and rebuilding a duplex protocol badly out of one request per message. The choice is direction and rate first, everything else after.

  • When does a duplex socket genuinely win over a one-way event stream?
    When upstream traffic is continuous rather than occasional — interactive input, drag positions, per-frame telemetry — where one request per message is the latency budget. Also when binary payloads travel in volume, since a text body forces encoding and roughly a third more bytes, or when both ends already speak an application subprotocol designed for a socket.
  • Can a client that is not a browser consume a Server-Sent Events stream?
    Yes. It is an ordinary HTTP response with `Content-Type: text/event-stream`, so any client that reads a body incrementally can parse the line grammar. What a non-browser client does not get for free is the behaviour: re-opening after a drop and presenting the last event `id` are things its library must do, or that you write.
  • Does choosing an event stream rule out binary payloads?
    Not literally, but it taxes them. The body is UTF-8 text, so binary has to be encoded before it goes into `data` — roughly a third more bytes plus encode and decode work on both ends. For occasional small blobs that is noise; for a continuous feed of images or frames it is often the argument that settles the choice.

A one-way stream is a letter slot in your door: the mountain can post through it all day, and anything you want to say back you carry round to the desk yourself. A socket is a doorway both of you walk through.

saying these in an interview costs you the question

  • Claims a Server-Sent Events stream can carry client messages upstream
  • Says a WebSocket connection re-opens itself the way an event stream does
  • Thinks Server-Sent Events only works in browsers, not in any HTTP client
  • Picks a socket because the brief said live, without checking direction
  • Assumes the event stream is cheaper simply because it is still HTTP