Server-Sent Events
What are server-sent events?
Server-sent events, or SSE, are a web technology that lets a server continuously push one-way updates to a browser through a long-lived HTTP connection. They work well for live notifications, status changes, dashboards, and streamed AI responses. In the browser, the EventSource API opens and listens to the event stream, while the server sends messages as plain text.
How server-sent events work
SSE keeps a normal web response open instead of returning one response and closing it.
- The browser requests an endpoint that returns the
text/event-streamcontent type. - The server keeps the HTTP response open and writes updates as they occur.
- Each update can include
data, an optional event name, an event ID, and a reconnect delay. - EventSource delivers default messages or named events to browser code.
- After an interruption, the browser reconnects automatically and can send the last received event ID so the server can resume or replay updates.
Server-sent events vs WebSockets vs long polling
The right choice depends mainly on whether the client must send live messages back on the same connection.
| Approach | Direction | Best fit |
|---|---|---|
| SSE | Server to browser | Alerts, progress, feeds, AI streaming |
| WebSockets | Two-way | Chat, games, collaboration, live controls |
| Long polling | Mostly server to browser | Older compatibility needs or infrequent updates |
Choose SSE when updates only travel to the browser. Choose WebSockets for low-latency two-way interaction. WebSockets are not deprecated, they solve a different communication problem.
Benefits of server-sent events
SSE is intentionally simple and uses familiar web infrastructure.
- It runs over standard HTTP and HTTPS, which can simplify deployment.
- Browsers provide native EventSource support and reconnection behavior.
- Named events let one stream carry different update types.
- It suits live feeds, job progress, alerts, monitoring views, and incremental AI output.
Practical limitations of SSE
SSE is not a universal replacement for every real-time protocol.
- The stream is one-way, so client actions require separate HTTP requests.
- Event payloads are text, although they can contain JSON.
- Some HTTP/1.1 browser conditions limit concurrent connections per origin.
- Load balancer timeouts and proxy buffering can delay or end a stream.
- Servers must safely manage many open client connections.
Reliable SSE implementation practices
Reliable streams need operational design, not only an endpoint.
- Send periodic heartbeat comments to prevent idle connection timeouts.
- Disable proxy buffering where infrastructure requires it.
- Assign event IDs, define a limited replay window, and handle missed events.
- Use secure cookies or short-lived tokens, then verify authorization on every connection.
- Set appropriate cache-control headers, clean up resources on disconnect, and monitor connection counts and error rates.
Using SSE in applications built with Emergent
Emergent can help turn a requirement such as streamed AI output, background-task progress, or a live operations screen into a full application. When building an AI web app, SSE is a practical fit for displaying generated text as it arrives. It can also support live operational views such as server monitoring dashboards, where users need timely updates without sending continuous two-way messages.
on Emergent today

