Kiedy użyć WebSocketów, SSE lub long-pollingu zamiast zwykłego HTTP?

Question

IT Interview Practice · Accepted Answer

Zwykłe HTTP to **żądanie/odpowiedź**: klient pyta, serwer odpowiada, koniec. To słabe dopasowanie do funkcji **czasu rzeczywistego** (czat, dashboardy na żywo, powiadomienia, współpraca przy edycji), gdzie *serwer* musi wypychać dane, ilekroć ma coś nowego. Opcje to sposoby obejścia zainicjowanego-przez-klienta modelu HTTP, wzdłuż spektrum złożoności:

```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** to fallback, który działa wszędzie: klient wykonuje zwykłe żądanie, które serwer trzyma otwarte, dopóki nie ma danych, a potem klient natychmiast ponawia. Przybliża push nad zwykłym HTTP, ale marnuje cykl żądania na wiadomość i dodaje opóźnienie.

**SSE (Server-Sent Events)** to lekki, ustandaryzowany **jednokierunkowy** strumień (serwer → klient) nad pojedynczą, długo żyjącą odpowiedzią HTTP. Jest idealny, gdy tylko serwer wypycha — kanały na żywo, powiadomienia, postęp, strumieniowanie tokenów LLM. Jest prosty, działa nad zwykłym HTTP/2 (bez specjalnej infrastruktury) i sam się wznawia. Ograniczenie: jest jednokierunkowy i tylko tekstowy.

**WebSockety** podnoszą pojedyncze połączenie HTTP do trwałego, **full-duplex** kanału TCP, gdzie obie strony wysyłają w dowolnym momencie z minimalnym narzutem na wiadomość. Używaj go do prawdziwie dwukierunkowej interakcji o niskim opóźnieniu: czat, gry wieloosobowe, edytory współdzielone, trading. Kosztem jest strona operacyjna — to stanowe połączenie, dla którego proxy, load balancery i autoskalery muszą być skonfigurowane, a ponowne łączenie, heartbeaty i backpressure musisz zbudować sam.

**Reguła kciuka:** domyślnie zwykłe HTTP; użyj **SSE** do strumieniowania serwer→klient; sięgnij po **WebSockety** tylko, gdy naprawdę potrzebujesz dwukierunkowego czasu rzeczywistego; trzymaj **long-polling** jako uniwersalny fallback.

## Dlaczego to ważne

Wybór transportu czasu rzeczywistego to klasyczna decyzja projektowa seniora, gdzie naiwna odpowiedź („po prostu użyj WebSocketów do wszystkiego") jest zwykle błędna. Rekruterzy chcą zobaczyć, że dopasowujesz narzędzie do *wzorca komunikacji* — jednokierunkowy vs dwukierunkowy, potrzeby opóźnienia, wolumen wiadomości — i że ważysz **koszt operacyjny** stanowych, długo żyjących połączeń: sticky sessions, skalowanie, timeouty proxy i logika ponownego łączenia. Rozpoznanie, że SSE często pokrywa „serwer wypycha aktualizacje" prościej niż WebSockety, i że long-polling pozostaje solidnym fallbackiem, sygnalizuje prawdziwe doświadczenie produkcyjne, a nie sięganie po najbardziej efektowną opcję.

Dlaczego to ważne

Powiązane pytania