Når vil du bruke WebSockets, SSE eller long-polling i stedet for vanlig HTTP?

Question

IT Interview Practice · Accepted Answer

Vanlig HTTP er **request/response**: klienten spør, serveren svarer, ferdig. Det passer dårlig for **sanntidsfunksjoner** (chat, live dashboards, varsler, samtidig redigering) der *serveren* må pushe data når som helst den har noe nytt. Alternativene er måter å komme rundt HTTP-ens klient-initierte modell på, langs et spekter av kompleksitet:

```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** er reserveløsningen som virker overalt: klienten gjør en vanlig forespørsel som serveren holder åpen til den har data, deretter forespør klienten umiddelbart på nytt. Den tilnærmer push over vanlig HTTP, men sløser en forespørselssyklus per melding og legger til latency.

**SSE (Server-Sent Events)** er en lettvekts, standardisert **enveis**-strøm (server → client) over én langlevd HTTP-respons. Den er ideell når bare serveren pusher — live feeds, varsler, fremdrift, streaming av LLM-tokens. Den er enkel, kjører over vanlig HTTP/2 (ingen spesiell infrastruktur) og kobler seg til på nytt automatisk. Begrensningen: den er enveis og kun tekst.

**WebSockets** oppgraderer en enkelt HTTP-tilkobling til en varig, **full-duplex** TCP-kanal der begge sider sender når som helst med minimal overhead per melding. Bruk den til ekte toveis, lav-latency-interaksjon: chat, flerspillerspill, samtidige editorer, trading. Kostnaden er operasjonell — det er en stateful tilkobling som proxy-er, load balancers og autoscalere må konfigureres for, og du må selv bygge reconnection, heartbeats og backpressure.

**Tommelfingerregel:** bruk vanlig HTTP som standard; bruk **SSE** for server→client-streaming; grip til **WebSockets** bare når du virkelig trenger toveis sanntid; behold **long-polling** som den universelle reserveløsningen.

## Hvorfor det er viktig

Å velge en sanntidstransport er en klassisk senior designbeslutning der det naive svaret («bare bruk WebSockets til alt») vanligvis er feil. Intervjuere vil se at du matcher verktøyet til *kommunikasjonsmønsteret* — enveis vs toveis, latency-behov, meldingsvolum — og at du veier den **operasjonelle kostnaden** av stateful, langlevde tilkoblinger: sticky sessions, skalering, proxy-timeouts og reconnection-logikk. Å innse at SSE ofte dekker «serveren pusher oppdateringer» enklere enn WebSockets, og at long-polling forblir en robust reserveløsning, signaliserer ekte produksjonserfaring i stedet for å gripe til det mest prangende alternativet.

Hvorfor det er viktig

Relaterte spørsmål