Server-Sent Events (SSE)

# Overview Sever-sent Events (SSE) are... #flashcard Similar to [[long polling]], but are more efficient because there is no long-standing connection that needs to run and be maintained. It uses a single, long-lived [[HTTP(S)]] connection that allows servers to initiate and send communication to the client. This means it is done without the client re-establishing the connection as seen in long polling and without the ability for the client to send data in a bi-directional communication as seen in [[WebSockets]]. How SSE works: 1. Client establishes SSE connection 2. Server keeps connection open 3. Server sends messages when data changes or updates happen 4. Client receives updates in real-time  # Key Considerations of SSE #flashcard - Since SSE is designed for a unidirectional communication between the server and client it is simpler to implement and integrate into existing HTTP infrastructure, such as [[Load Balancer]] and [[Firewall]]s. - SSE instead uses a special header `Transfer-Encoding: chunked` which tells the client that the response is a series of chunks - we don't know how many there are or how big they are until we send them. - Infrastructure doesn't handle it well: [Server Sent Events are still not production ready after a decade. A lesson for me, a warning for you! - DEV Community](https://dev.to/miketalbot/server-sent-events-are-still-not-production-ready-after-a-decade-a-lesson-for-me-a-warning-for-you-2gie) - Most SSE connections won't be super-long-lived (e.g. 30-60s is pretty typical), so if you need to send messages for a longer period you'll need to talk about how clients re-establish connections and how they deal with the gaps in between. The [SSE standard](https://html.spec.whatwg.org/multipage/server-sent-events.html) includes a "last event ID" which is intended to cover this gap, and the EventSource object in browsers explicitly handles this reconnection logic. If a client loses its connection, it can reconnect and provide the last event ID it received. The server can then use that ID to send all the events that occurred while the client was disconnected.  Also, you must consider how the servers will send the data to the client. Approaches include: - Pushing via [[Consistent Hashing]] - Pushing via [[Pub-sub]] # Pros for SSE #flashcard - Simple to implement - More efficient when compared to long polling - Simpler to integrate into existing HTTP infrastructure (load balancers, firewalls) when compared to WebSockets - Automatic reconnection  # Cons for SSE #flashcard - One-way communication only - Limited browser support (not an issue for modern browsers) - Some proxies and networking equipment don't support streaming. Nasty to debug! - Browsers limit the number of concurrent connections per domain, meaning you may only be able to have a few SSE connections per domain - Makes monitoring more painful since requests can hang around for a long time  # Use Cases for SSE #flashcard - AI chat apps which frequently involve the need to stream new tokens (words) to the user as they are generated to keep the UI responsive - [[Design an Auction Website]]  --- Items to discuss when using SSE in a system design interview: #flashcard - Infrastructure gap - Many proxies and load balancers don't support streaming responses. In these cases, the proxy will try to buffer the response until it completes - which effectively blocks our stream in an annoying, opaque way that is hard to debug! - If you need to send messages for a longer period you'll need to talk about how clients re-establish connections and how they deal with the gaps in between. The [SSE standard](https://html.spec.whatwg.org/multipage/server-sent-events.html) includes a "last event ID" which is intended to cover this gap, and the EventSource object in browsers explicitly handles this reconnection logic. If a client loses its connection, it can reconnect and provide the last event ID it received. The server can then use that ID to send all the events that occurred while the client was disconnected.  --- # Related Topics