Server-Sent Events maintain an HTTP connection where the server streams text events to the browser.
Ideal workloads
- Live dashboards, notifications, incremental logs.
- Simpler than WebSockets when only server→client pushes matter.
API surface
const source = new EventSource('/stream');
source.onmessage = (event) => { console.log(event.data); };Operational concerns
- Reconnect semantics built into
EventSource. - Proxies/CDNs may buffer—configure timeouts accordingly.
- Use HTTPS to prevent tampering.
Compared to WebSockets
Choose WebSockets when you need bidirectional binary chatter at low latency.
Infrastructure pitfalls
- Reverse proxies buffering SSE—explicit flush / timeout tuning required.
- Auth on long-lived streams: cookies vs tokens—expiration mid-stream UX.
Minimal server response headers
HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
data: {"price":41.02}
data: heartbeat
Clients reconnect automatically; authenticate the stream endpoint like any API.
Rendered output (status region only)
Waiting for server events…
Your script updates this node when EventSource receives message events.
Important interview questions and answers
- Q: What does progressive enhancement mean in API-driven pages?
A: Core tasks should work with baseline HTML first, then richer APIs enhance experience when supported. - Q: Why is feature detection better than browser sniffing?
A: It checks actual capability, avoids brittle UA assumptions, and degrades gracefully. - Q: What is the first accessibility check before shipping any page?
A: Verify keyboard-only task completion with visible focus and meaningful accessible names.
Tip: SSE is one-way server→client; WebSockets are bidirectional.