Kdy byste použili WebSockets, SSE nebo long-polling místo prostého HTTP?

Question

IT Interview Practice · Accepted Answer

Prosté HTTP je **request/response**: klient se ptá, server odpovídá, hotovo. To se špatně hodí pro **real-time** funkce (chat, živé dashboardy, notifikace, kolaborativní editace), kde *server* potřebuje posílat data, kdykoli má něco nového. Možnosti jsou způsoby, jak obejít model HTTP iniciovaný klientem, na spektru složitosti:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** je záložní řešení, které funguje všude: klient pošle normální request, který server drží otevřený, dokud nemá data, pak klient okamžitě požádá znovu. Napodobuje push přes prosté HTTP, ale plýtvá jedním cyklem requestu na zprávu a přidává latency.

**SSE (Server-Sent Events)** je lehký, standardizovaný **jednosměrný** stream (server → client) přes jedinou dlouho žijící HTTP response. Je ideální, když posílá jen server — živé feedy, notifikace, průběh, streamování LLM tokenů. Je jednoduchý, běží přes normální HTTP/2 (bez speciální infrastruktury) a automaticky se znovu připojuje. Omezení: je jednosměrný a jen textový.

**WebSockets** povyšují jediné HTTP spojení na trvalý, **full-duplex** TCP kanál, kde obě strany posílají kdykoli s minimální režií na zprávu. Použijte je pro skutečně obousměrnou interakci s nízkou latency: chat, hry pro více hráčů, kolaborativní editory, obchodování. Cena je provozní — je to stavové spojení, pro které musí být nakonfigurovány proxy, load balancery a autoscalery, a reconnection, heartbeaty a backpressure si musíte postavit sami.

**Pravidlo palce:** výchozí volbou je prosté HTTP; použijte **SSE** pro streamování server→client; po **WebSockets** sáhněte, jen když skutečně potřebujete obousměrný real-time; **long-polling** si nechte jako univerzální záložní řešení.

## Proč je to důležité

Volba real-time transportu je klasické seniorní návrhové rozhodnutí, kde je naivní odpověď ("prostě použij WebSockets na všechno") obvykle špatná. Tazatelé chtějí vidět, že přiřazujete nástroj k *komunikačnímu vzorci* — jednosměrný vs obousměrný, nároky na latency, objem zpráv — a že zvažujete **provozní náklady** stavových, dlouho žijících spojení: sticky sessions, škálování, proxy timeouty a logiku reconnection. Rozpoznání, že SSE často pokryje "server posílá aktualizace" jednodušeji než WebSockets a že long-polling zůstává robustním záložním řešením, signalizuje skutečnou produkční zkušenost, ne sáhnutí po nejokázalejší možnosti.

Proč je to důležité

Související otázky