SSE and long polling

Когда сервер пушит обновления, а клиенту нужен только **one-way** stream, SSE и long polling часто проще WebSockets.

**Server-Sent Events (SSE)** — HTTP-ответ остаётся открытым; сервер пишет кадры `text/event-stream`:

					GET /events/orders
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

event: order.created
id: 1024
data: {"orderId":"ord_9"}

: keepalive

event: order.updated
id: 1025
data: {"orderId":"ord_9","status":"SHIPPED"}
				

Браузерный `EventSource` автоматически переподключается и шлёт `Last-Event-ID` для resume. Прокси не должны бесконечно буферизовать SSE — настройте nginx/load balancers.

**Long polling**: клиент запрашивает; сервер держит до события или timeout, затем клиент сразу переподключается. Больше overhead, работает везде, где есть HTTP.

| | SSE | Long polling | WebSocket | |---|-----|--------------|-----------| | Направление | server → client | server → client | двунаправленный | | Browser API | EventSource | fetch/XHR | WebSocket | | Binary | нет (text) | да | да |

На интервью: SSE для notification feeds, long polling при legacy-ограничениях, proxy buffering pitfalls.

Типовые ошибки: нет обработки Last-Event-ID, нет keepalive comments, CORS на EventSource, long poll timeouts без client backoff.

Компромисс: простота и HTTP compatibility против bidirectional needs — не выбирайте WebSocket по умолчанию для one-way feeds.

Чеклист:

• SSE для one-way text events с resume ids.
• Keepalive и согласование proxy timeout.
• Exponential backoff при reconnect.
• Long poll только если SSE заблокирован.