Real-Time APIs · Real-Time Transports

The Real-Time Landscape

Choosing between polling, long polling, SSE, WebSockets, webhooks and push.

"Real-time" covers different needs: UI updates in browsers/apps (notifications, dashboards, chat), server-to-server events (webhooks), and mobile background notifications (APNs/FCM push). Pick the simplest transport that meets latency and direction requirements: polling for low-frequency updates, SSE for server→client streams over plain HTTP, WebSockets for bidirectional low-latency messaging, webhooks for integrations, push notifications for devices that aren't connected.

Transport comparison

Criterion Polling Long polling SSE WebSockets Webhooks
Direction Client pulls Client pulls (held) Server → client Bidirectional Server → server
Latency Interval Low Low Lowest Seconds
Protocol HTTP HTTP HTTP (text/event-stream) WS upgrade HTTP POST
Auto-reconnect N/A Manual Built in (EventSource) Manual Provider retries
Infra friendliness Excellent Good Good (HTTP/2) Needs WS support Excellent
Best for Rare updates Legacy fallbacks Feeds, progress, LLM tokens Chat, games, collaboration Integrations

Common pitfalls

  • WebSockets for one-way notifications (SSE is simpler).
  • Polling every second at scale.
  • Expecting browsers to keep connections alive in background tabs/mobile.

Key points

  • Match transport to direction and latency
  • SSE for one-way streams
  • WebSockets for bidirectional

Further reading: MDN: WebSockets API

Practice questions

When is SSE a better choice than WebSockets?

Answer

When updates only flow server→client (feeds, progress, LLM token streams): SSE uses plain HTTP, reconnects automatically and works well with existing infrastructure.

How do mobile apps get real-time updates when they're in the background?

Answer

Through platform push notifications (APNs/FCM); persistent sockets are typically suspended by the OS in the background.

Open in the app to mark lessons complete, take notes and track your progress.