WebSockets aren't the only real-time tool — and often not the right one. The full menu:
Server-Sent Events — the underrated middle
// client — built into every browser
const es = new EventSource("/api/notifications");
es.onmessage = (e) => showNotification(JSON.parse(e.data));
// auto-RECONNECTS on drops — WebSockets don't!
// Express server
app.get("/api/notifications", (req, res) => {
res.setHeader("Content-Type", "text/event-stream");
res.setHeader("Cache-Control", "no-cache");
const timer = setInterval(() => {
res.write(`data: ${JSON.stringify({ time: Date.now() })}
`);
}, 5000);
req.on("close", () => clearInterval(timer));
});The decision table
- Polling (fetch every N seconds): dead simple, fine for dashboards refreshing each minute. Start here, honestly
- SSE (server → client only): notifications, live scores, AI-answer streaming (ChatGPT-style streaming IS SSE), build progress. Plain HTTP — proxies and auth just work
- WebSockets (both directions): chat, multiplayer games, collaborative editing — anything where the CLIENT also pushes frequently
The interview answer
"One-directional server push → SSE (simpler, auto-reconnect, plain HTTP). Bidirectional → WebSockets. Neither needed → poll." Choosing the boring right tool over the shiny one is exactly what senior engineers listen for.