When to use server sent events
Use server sent events when the interface needs server initiated updates such as processing progress, incident status or a changing invoice review queue. Keep commands on a separately authenticated request path. A persistent stream should not be the only way a user can retrieve the current state.
Compare the required update frequency with polling before adding connection lifecycle complexity. A stream is useful when timely changes matter, but it still needs proxy configuration, connection limits and a recovery policy. The transport does not make the underlying data fresh or authoritative by itself.
Use the defined event stream format
The response uses the text/event-stream media type and UTF-8 text. A blank line completes an event. The event field names a message category, data carries text and id establishes the browser's last event identifier. Multiple data lines are joined using newline characters by the parser.
Keep each payload small and interpretable. A lightweight notification can tell the browser which resource changed, followed by an authorized HTTP fetch for the current resource. If a payload is JSON, validate it after parsing rather than treating valid stream framing as evidence of a valid business object.
id: cursor_2048
event: invoice.updated
data: {"invoiceId":"inv_1042","status":"approved"}
Recover missed events after reconnection
EventSource normally reconnects after eligible interruptions. If its last event ID is nonempty, the browser sends Last-Event-ID on reconnection. This gives the server a cursor; the standard does not require the server to retain or replay the corresponding history.
Specify cursor retention, authorization and expiration behavior. When history is unavailable, tell the client to refresh a snapshot and resume from a valid point. Deduplicate replayed updates or apply resource versions. Otherwise a reconnect can repeat a notification or overwrite a newer view with older state.
Bound queues and observe connection health
A slow client must not create an unlimited server queue. Set byte and message limits, then choose a policy such as disconnecting with a recoverable cursor or coalescing updates that represent replaceable state. Never silently coalesce events whose individual effects matter.
Check buffering and idle timeouts across reverse proxies and load balancers. Comment lines can support a heartbeat convention without becoming business events. Measure connected clients, reconnect rate, buffered bytes and the age of the latest applied update rather than displaying connected as a guarantee of fresh data.
Make browser session behavior explicit
Native EventSource accepts a URL and credential mode, but does not provide arbitrary request headers. Choose an authentication design that fits browser constraints and the site's origin policy. Avoid placing durable bearer credentials in URLs, where infrastructure may record them.
Close the stream when its owning view is disposed, and reconnect after session changes only under the new authorization context. Test an expired session, a background tab, a lost connection and an expired cursor. The interface should expose stale or reconnecting state without discarding the user's work.