Πότε θα χρησιμοποιούσες WebSockets, SSE ή long-polling αντί για σκέτο HTTP;

Question

IT Interview Practice · Accepted Answer

Το σκέτο HTTP είναι **request/response**: ο client ρωτά, ο server απαντά, τέλος. Αυτό ταιριάζει άσχημα σε **real-time** λειτουργίες (chat, live dashboards, ειδοποιήσεις, συνεργατική επεξεργασία) όπου ο *server* χρειάζεται να σπρώξει (push) δεδομένα όποτε έχει κάτι νέο. Οι επιλογές είναι τρόποι να παρακάμψεις το μοντέλο του HTTP που ξεκινά από τον client, κατά μήκος ενός φάσματος πολυπλοκότητας:

```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** είναι το fallback που δουλεύει παντού: ο client κάνει ένα κανονικό request που ο server κρατά ανοιχτό μέχρι να έχει δεδομένα, και μετά ο client ξανακάνει αμέσως request. Προσεγγίζει το push πάνω από σκέτο HTTP αλλά σπαταλά έναν κύκλο request ανά μήνυμα και προσθέτει latency.

Το **SSE (Server-Sent Events)** είναι ένα ελαφρύ, τυποποιημένο **μονόδρομο** stream (server → client) πάνω από μία μόνη μακρόβια HTTP response. Είναι ιδανικό όταν μόνο ο server κάνει push — live feeds, ειδοποιήσεις, πρόοδος, streaming tokens από LLM. Είναι απλό, τρέχει πάνω σε κανονικό HTTP/2 (χωρίς ειδική υποδομή), και κάνει auto-reconnect. Ο περιορισμός: είναι μονόδρομο και μόνο κειμένου.

Τα **WebSockets** αναβαθμίζουν μια μοναδική HTTP σύνδεση σε ένα μόνιμο, **full-duplex** TCP κανάλι όπου και οι δύο πλευρές στέλνουν οποτεδήποτε με ελάχιστο overhead ανά μήνυμα. Χρησιμοποίησέ τα για γνήσια αμφίδρομη, χαμηλού latency αλληλεπίδραση: chat, multiplayer games, συνεργατικούς editors, trading. Το κόστος είναι λειτουργικό — είναι μια stateful σύνδεση για την οποία πρέπει να ρυθμιστούν proxies, load balancers και autoscalers, και πρέπει να χτίσεις ο ίδιος το reconnection, τα heartbeats και το backpressure.

**Κανόνας του αντίχειρα:** προεπίλεξε το σκέτο HTTP· χρησιμοποίησε **SSE** για streaming server→client· κατέφυγε σε **WebSockets** μόνο όταν πραγματικά χρειάζεσαι αμφίδρομο real-time· κράτα το **long-polling** ως το καθολικό fallback.

## Γιατί έχει σημασία

Η επιλογή ενός real-time transport είναι μια κλασική senior απόφαση σχεδιασμού όπου η αφελής απάντηση («απλώς χρησιμοποίησε WebSockets για τα πάντα») είναι συνήθως λάθος. Οι συνεντευκτές θέλουν να δουν ότι ταιριάζεις το εργαλείο με το *μοτίβο επικοινωνίας* — μονόδρομο έναντι αμφίδρομου, ανάγκες latency, όγκος μηνυμάτων — και ότι ζυγίζεις το **λειτουργικό κόστος** των stateful, μακρόβιων συνδέσεων: sticky sessions, scaling, timeouts των proxies, και λογική reconnection. Το να αναγνωρίζεις ότι το SSE συχνά καλύπτει το «ο server σπρώχνει ενημερώσεις» πιο απλά από τα WebSockets, και ότι το long-polling παραμένει ένα ανθεκτικό fallback, δείχνει πραγματική εμπειρία production αντί να κατέφυγε στην πιο εντυπωσιακή επιλογή.

Γιατί έχει σημασία

Σχετικές ερωτήσεις