In our daily lives we’re not accustomed to measuring interactions in milliseconds, but when it comes to anything digital, an extra 100-200 milliseconds is noticeable “lag”. If the delay is bumped up to 300 milliseconds, an app will often be reported as “sluggish”, and if the hold-up is over 1000 milliseconds (just 1 second!), many users will lose focus, or even worse, close the app altogether. Considering that an average blink takes 400 milliseconds, user engagement (and subsequently business) can literally be lost in the blink of an eye.
To deliver modern, responsive experiences, data needs to be proactively pushed/streamed to end users. The internet, which was initially built around the HTTP request-response model, wasn’t designed for this, and so over the years developers have had to come up with new technologies to unlock “realtime” interaction patterns over the web. One of these, is Server-Sent Events (SSE) — a lightweight, open protocol that allows servers to proactively push data to clients over a standard HTTP connection.
This article covers the basics of Server-Sent Events — what are they, how they work, and why they’re needed. It also touches upon some of the security challenges that SSE may introduce and how to potentially overcome them.
Server-Sent Events is a standardized push technology that enables sending notifications, messages and events from a server to a client via an HTTP request. First conceptualized in 2004, it was included as part of the HTML5 specification, and today it’s supported by all browsers and web/mobile application environments.
With SSE, servers expose a URL through which clients subscribe to automatic message updates or continuous streams of data. It removes the need for (and complexity of) polling a server for the latest data and supports delivering “realtime” digital experiences.
SSE provides a connection management layer and parsing logic that enable an HTTP response to be kept open while a server pushes new events to a client as they become available. The three main components of SSE are:
The EventSource API is a standard interface that defines how browsers and servers can communicate with each other using SSE.
When a web client wants to receive updates from a server via SSE, it first creates an EventSource object. This object represents the event stream between the client and server and carries different methods for processing events.
So, first the SSE client sends a request…
SSE’s auto-reconnect capabilities are particularly useful when there’s a need to reliably deliver data to clients that may have unstable connectivity, such as mobile phones in “spotty” reception areas.
SSE is an elegant solution for pushing/streaming data between a server and a client. Compared to other streaming protocols and technologies, such as WebSocket, MQTT or proprietary pub/sub services, SSE is easier to get started with and manage. However, there are certain limitations to consider.
For web applications and websites that need to operate asynchronously or in “realtime”, and there is no requirement for bi-directional data streaming between the client and server, SSE is a great fit. Some exciting use cases for SSE include:
Not only do different clients often have different data access privileges, but these privileges may change at any time. Ensuring that a client is consistently authorized to access a server is a critical security requirement, especially in an enterprise setting.
With HTTP request-response, client to server communication is batched, and as a result each request for data can be authenticated without any impact on user experience.
With SSE, a client only makes a single request, after which an open connection is established. While the initial request can be authenticated via the same techniques as in the request-response case, how should re-authentication be handled for a client that’s in the midst of consuming a data stream?
The naive approach would be to simply terminate the SSE stream after a set period of time and have the client re-authenticate when it goes to establish a new request, but this disrupts the continuous nature of streaming, and leads to a frustrating user experience.
One way of handling the authentication challenges presented by SSE is with Zilla Continuous Stream Authorization.
Zilla is an open source event-driven API gateway that can act as an SSE reverse-proxy. When deployed between an SSE client and server, it gracefully re-authorizes the client on the server’s behalf, without abruptly terminating message streams.
Continuous Authorization with Zilla works as follows:
In summary, Zilla helps deliver a secure and smooth user experience with SSE.
Server-Sent Events are a great way to extend the reach of Apache Kafka-based event-driven architectures to the edge. Besides a vanilla SSE Proxy, Zilla can also be configured as a Kafka-SSE Proxy. In such a configuration, Zilla maps Kafka event streams to SSE streams and enables web clients to consume data directly from a Kafka topic.
With Zilla, Kafka can be turned into a fully fledged, asynchronous backend for mobile and browser applications, eliminating the need for a dedicated SSE server.
The world happens in “realtime”, so data should reach end users likewise. Server-Sent Events (SSE) is standardized technology that supports pushing updates and continuously streaming data to web-based clients. Unlike other approaches, SSE comes with powerful features such as auto-reconnect built-in, and is HTTP-based, so it’s easy and familiar to get started with. While it does have some limitations, such as being unidirectional, SSE ultimately can help accelerate the delivery of modern digital experiences.