What are WebSockets and streaming?
Most HTTP is request-response: the client asks, the server answers, the connection closes. Real-time features need more — a persistent channel for the server to push data as it happens. WebSockets give a two-way connection; server-sent events give a simpler one-way stream.
Why it matters
Chat, live dashboards, notifications, and collaborative editing all need the server to push without being asked. These patterns also introduce stateful connections, which scale differently from stateless HTTP. Knowing the options and their costs lets you build real-time features that hold up under load.
What to learn
- WebSockets: the upgrade handshake and bidirectional messages
- Server-sent events for simple one-way streams
- When polling is good enough
- Connection state and why it complicates scaling
- Backpressure when a client reads slower than the server writes
- Heartbeats, reconnection, and dropped connections
- Broadcasting across multiple server instances
Common pitfall
Forgetting that WebSocket connections are stateful and pinned to one server process. With several instances behind a load balancer, a message published on one is not seen by clients connected to another. You need a shared pub/sub layer — often Redis — to broadcast across instances.
Resources
Primary (free):
- MDN — WebSockets API · docs
- MDN — Server-sent events · docs
- Ably — WebSockets vs SSE · article
Practice
Build a tiny live counter: a WebSocket endpoint that pushes the current value to all connected clients whenever it changes. Open two browser tabs and confirm both update together. Then describe what would break if you ran two server instances, and how a shared pub/sub layer fixes it.
Outcomes
- Choose between WebSockets, SSE, and polling for a feature.
- Explain the WebSocket upgrade and bidirectional messaging.
- Handle reconnection and heartbeats for dropped connections.
- Broadcast across instances with a shared pub/sub layer.