Long Polling vs WebSockets vs SSE
You'll learn to
- -Compare three techniques for pushing server data to a client
The Problem: HTTP Doesn't Push
Back in Module 1, HTTP was described as a request-response protocol: the client asks, the server answers, done. That model breaks down the moment you need the server to tell the client something the instant it happens (a new chat message, a live score, a price change) without the client having to ask first.
Long Polling
The client sends a request and the server holds it open: not responding until there's new data, or a timeout is reached. The moment the client gets a response, it immediately sends another request. It works over plain HTTP with no special infrastructure, but wastes resources holding connections open and adds latency between the response and the next request.
Server-Sent Events (SSE)
A single long-lived HTTP connection over which the server can push a continuous stream of events to the client. Simple and works over plain HTTP, but strictly one-directional: the client can't send data back over the same connection.
WebSockets
A true bidirectional, persistent connection: both sides can send messages at any time, with none of the request/response overhead. This is the right tool when the client needs to talk back just as urgently as it needs to listen.
Normal HTTP requests are like sending letters: you send a question, wait for a reply, and the connection closes. WebSockets are like a phone call. You dial once, and then both sides can talk to each other anytime without hanging up. A WebSocket server keeps a persistent, always-open connection with each client. This means the SERVER can push data to the client instantly, without the client asking. Imagine a chat app: without WebSockets, your browser would have to ask the server 'Any new messages?' every second (called polling), which wastes bandwidth and battery. With WebSockets, the server instantly pushes new messages the moment they arrive. Zero delay, zero wasted requests. This is how WhatsApp Web, Slack, Google Docs collaborative editing, live sports scores, and stock tickers work in real-time.
Examples: Socket.io, ws (Node.js library), STOMP (Spring), Pusher, Ably, AWS API Gateway WebSocket
- -Need one-off updates, simplicity over efficiency? Long polling.
- -Need server-to-client only, over plain HTTP (live scores, price tickers)? SSE.
- -Need true two-way, low-latency communication (chat, multiplayer, collaborative editing)? WebSockets.
A WebSocket connection is a single, long-lived, bidirectional pipe, unlike a fresh HTTP request/response for every message.
Why not just use WebSockets for everything, since they seem strictly more capable than SSE or long polling?
"You should, since WebSockets can do everything the others can and more."
"Capability isn't the only cost. A WebSocket is a stateful, persistent connection that a server has to hold open and a load balancer has to route consistently: real infrastructure cost at scale, for a feature (bidirectional push) many use cases don't actually need. A stock ticker only needs server-to-client; SSE gets that over plain HTTP with far less operational weight. I'd reach for WebSockets specifically when the client genuinely needs to send data back with the same urgency it receives it."