เหตุการณ์ที่ส่งจากเซิร์ฟเวอร์เทียบกับ WebSockets

WebSockets are not the only option. Server-Sent Events (SSE) give a simpler, one-way streaming channel from server to client over plain HTTP.

SSE pushes a continuous stream of text events to the browser over one long-lived HTTP connection, received via the EventSource API. It is one-way only.

SSE uses a simple, line-based wire format over the text/event-stream content type — just data: and optional event: fields.

The client subscribes with EventSource, and the browser automatically reconnects if the stream drops — no manual retry logic needed.

SSE has reconnection built in: the server sets the delay with a retry: field, and the client sends Last-Event-ID to resume where it left off.

SSE vs WebSockets: SSE is one-way over plain HTTP with auto-reconnect and text only; WebSockets are full-duplex, use their own protocol, and support binary.

Versus long polling, SSE keeps one connection open and streams many events, avoiding the cost of reopening a connection for every message.

Reach for SSE for one-way feeds: live notifications, activity streams, stock tickers, dashboards, job progress, and live scores.

Choose WebSockets when the client sends frequently too: chat, multiplayer, collaborative editing. If you only need server-to-client, SSE is simpler.

SSE has limits: text only, no binary; browsers cap connections per domain (eased by HTTP/2); and older environments may lack support.

A simple rule of thumb decides most cases — need client-to-server or binary? Pick WebSocket. Otherwise, SSE.

One feed, one direction, one connection — how well do you know SSE?

You learned Server-Sent Events: simple one-way streaming over HTTP with auto-reconnect, how they compare to WebSockets and long polling, and when to use each.