Stop 14 · Real-time CommunicationTopics · 4/6

Long Polling

Part of the Backend Developer Roadmap

In short

Before WebSockets were everywhere, apps faked real-time by asking the server a question and having it wait to answer. It still works anywhere HTTP works.

An older technique simulating real-time updates by having the client repeatedly request data, with the server holding the connection open until new data is available — mostly superseded by WebSockets/SSE but still seen as a fallback.

The blob waits at a post office counter with a desk bell as a hand slides an envelope out.

Think of it like this

Waiting at the post office counter

You ask the clerk, 'Any letter for me?' Instead of saying no and sending you home, he says, 'Wait here, it should come soon.' The moment it arrives, he hands it over, and you immediately ask about the next one. That's long polling.

Watch it happen

Ask, wait, answer, ask again

Browser
Server

GET /updates?since=41

1/5The browser asks for anything newer than message 41.

The big ideas

What you need to know

Held requests

The server doesn't answer until there's data or a timeout. Updates feel near-instant without new protocols.

Works everywhere

It's ordinary HTTP, so old proxies and strict firewalls are fine. Socket.io uses it as a fallback.

Overhead per message

Each message costs a full HTTP request and response, with headers. Fine for a few updates, wasteful for many.

Keep timeouts short

Proxies often cut idle connections after 30 to 60 seconds. Reply within that, then let the client re-ask.

See it in code

Walk through the code

ts
1import type { Response } from "express";2 3const waiting: Response[] = [];4 5app.get("/updates", (req, res) => {6  waiting.push(res);7  setTimeout(() => {8    const i = waiting.indexOf(res);9    if (i !== -1) { waiting.splice(i, 1); res.status(204).end(); }10  }, 25_000);11});12 13export function publish(msg: unknown) {14  while (waiting.length) waiting.shift()!.json(msg);15}

1/3Don't reply yet. Park the response object in a list of waiting clients.

Client side: async function loop() { const r = await fetch("/updates"); if (r.status === 200) show(await r.json()); loop(); }. A real version also tracks the last id.

Save yourself the pain

Common mistakes

Oops

Using short polling every second and calling it real-time.

Do this instead

Short polling hammers the server with empty replies. Long polling only answers when there's news.

Oops

Setting a 5 minute hold time.

Do this instead

Proxies and load balancers drop idle connections well before that. Stay under about 30 seconds.

Your mission

Build a long-poll notifier

~25 min

Quick check

In long polling, what does the server do when a request comes in and there's no new data?

Go deeper

  1. 1Implement a simple long-polling endpoint and observe the request pattern.
  2. 2Understand why long polling is less efficient than WebSockets for frequent updates.
  3. 3Recognize it as Socket.io's fallback mechanism for restrictive network environments.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge