Realtime: WebSocket and SSE

Open Tandem's live map and the dots move. Bikes leave Old Market, arrive at the river, and the numbers on each station tick up and down while you watch — dozens of small changes a minute, with nobody pressing refresh. Neither of Chapter 9's arrangements explains that. Polling every minute would show a slideshow, not a map, and a webhook for every bike that moves would be a knock at the door forty times a second.

Flows like this use a third arrangement: the connection stays open. WebSocket holds a line on which both sides may speak at any time, and Server-Sent Events, usually shortened to SSE, holds a line on which only the server speaks. Nine chapters of impeccable correspondence, and some conversations still want the telephone. You do not mail forty letters to follow one bike across town.

Pattern	Who starts it	The connection	Fits best
Polling	you, on a timer	opens and closes each time	the Thursday report: fresh enough, hourly
Webhooks	the provider, per event	opens and closes each time	ride rd_7c29 has ended
SSE	you open it, the server talks	held open, one direction	a dashboard that updates itself
WebSocket	you open it, both talk	held open, both directions	the live map, a chat window

The Line That Stays Open

Every exchange in this book has ended the same way: the answer arrives and the conversation is over. Ask again and you start a new one. That is request and response, and it is why polling has to keep asking — there is no line left open to listen on.

A WebSocket changes exactly one thing about that. It begins as an ordinary HTTP request, with the usual address and headers, and instead of answering and hanging up, the server agrees to keep the connection open. From that moment both sides may send small messages whenever they have something to say, in either direction, until one of them hangs up. The messages are usually JSON, so the reading skill from Chapter 4 arrives intact.

The shift is worth naming plainly, because it is the only genuinely new idea on this page. Everywhere else in this book, nothing arrives unless somebody asked. On an open line, things arrive because they happened.

SSE: the Simpler Sibling

Server-Sent Events is the same idea with half the machinery. You make one ordinary HTTP request, and the server answers with a response that never finishes: it keeps the body open and writes new events into it as they occur, one after another, for as long as the line lasts. Your side listens. Your side does not speak.

One direction covers more than it sounds like. A price ticker, a news feed, a progress bar for a long job, a dashboard that refreshes itself — none of those need to send anything back up the line, and SSE gives them what they need with plainer plumbing and fewer moving parts. It also travels through ordinary web infrastructure more easily, because it is, quite literally, one long HTTP response.

So the split is simple: if only the server has news, SSE is usually enough. If both sides need to speak — a chat window, a shared document, a game — you want WebSocket.

Which Pattern Fits Which Flow

You now own all three arrangements, which means you can judge any integration you are shown. Poll when you need occasional freshness and nothing more, as Chapter 9 established for the Thursday report. Take a webhook when there are discrete, meaningful events on the provider's side, like a ride ending. Hold a line open when the flow is continuous, or when both ends genuinely need to talk.

The mistake worth avoiding is treating this as a fashion contest, where newer means better. An open line costs both sides something real: a connection held for every user, a phone battery kept awake, reconnection logic for every dropped line, and a harder job for whoever has to keep the servers standing. Vera's report needs the state of 214 stations once a week. For that, polling is not the primitive option — it is the correct one, and knowing that is the sophistication.

Spotting One, and One More Tab

The recognition kit has two items. First, the address: an open line is written wss:// instead of https:// — the WebSocket scheme, with the same trailing "s" meaning the same encryption. Seeing wss:// in documentation tells you immediately which arrangement is on offer. Second, the docs themselves: a section called "realtime", "streaming" or "live events", sitting apart from the ordinary endpoint reference, is where providers keep this.

And there is one more place to look, which closes a loop from Chapter 3. When Vera pressed F12 and clicked Network, the filter row had more buttons than she noticed. One of them, labelled WS, narrows the list to WebSocket connections; click a connection and a Messages tab shows the individual messages flowing in both directions with timestamps — the same read-only window onto your own browser's conversations, pointed at the live half of the web. One catch carried over from Chapter 3: the panel only records what happens while it is open, so open it first and reload — then the moving dots stop being magic.

Consuming an open line from your own program is programming work, and this book does not do programming. That is not a gap in your skill. Your job with these is to recognize which arrangement a provider offers, understand what it will cost, and ask the right question in the room — and you can now do all three.