Kada biste koristili WebSockets, SSE ili long-polling umjesto običnog HTTP-a?

Question

IT Interview Practice · Accepted Answer

Obični HTTP je **request/response**: klijent pita, server odgovori, gotovo. To loše pristaje **real-time** značajkama (chat, uživo dashboardi, obavijesti, kolaborativno uređivanje) gdje *server* treba gurnuti podatke kad god ima nešto novo. Opcije su načini zaobilaženja HTTP-ovog modela koji pokreće klijent, duž spektra složenosti:

```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 rezervni pristup koji radi svugdje: klijent šalje običan request koji server drži otvorenim dok nema podataka, pa klijent odmah ponovno zatraži. Aproksimira push preko običnog HTTP-a, ali troši ciklus requesta po poruci i dodaje latenciju.

**SSE (Server-Sent Events)** je lagan, standardiziran **jednosmjeran** stream (server → client) preko jednog dugoživućeg HTTP responsea. Idealan je kad samo server gura — uživo feedovi, obavijesti, napredak, streamanje LLM tokena. Jednostavan je, radi preko običnog HTTP/2 (bez posebne infrastrukture) i automatski se ponovno spaja. Ograničenje: jednosmjeran je i samo tekst.

**WebSockets** nadograđuju jednu HTTP vezu u trajan, **full-duplex** TCP kanal gdje obje strane šalju bilo kad uz minimalan overhead po poruci. Koristite ga za istinski dvosmjernu, niskolatentnu interakciju: chat, multiplayer igre, kolaborativne editore, trgovanje. Cijena je operativna — to je stateful veza za koju proxyji, load balanceri i autoscaleri moraju biti konfigurirani, a ponovno spajanje, heartbeatove i backpressure morate sami izgraditi.

**Pravilo palca:** zadano koristite obični HTTP; koristite **SSE** za streamanje server→client; posegnite za **WebSocketsima** samo kad vam stvarno treba dvosmjerni real-time; zadržite **long-polling** kao univerzalni rezervni pristup.

## Zašto je to važno

Odabir real-time transporta klasična je senior dizajnerska odluka gdje je naivan odgovor ("samo koristi WebSockets za sve") obično pogrešan. Ispitivači žele vidjeti da usklađujete alat s *obrascem komunikacije* — jednosmjerno naspram dvosmjerno, potrebe za latencijom, volumen poruka — i da vagate **operativni trošak** stateful, dugoživućih veza: sticky sesije, skaliranje, proxy timeouti i logika ponovnog spajanja. Prepoznavanje da SSE često pokriva "server gura ažuriranja" jednostavnije od WebSocketsa, i da long-polling ostaje robustan rezervni pristup, signalizira stvarno produkcijsko iskustvo umjesto posezanja za najblještavijom opcijom.

Zašto je to važno

Povezana pitanja