Server-Sent Events are a great way to expose events to trusted third parties over the public internet. In this blog we will explore five ways to expose your existing messaging middleware to the internet: direct, polling, websockets, webhooks and server-sent events.
The classic way to deliver events is to trusted clients is to hook them up to your messaging middleware product, as shown in the diagram below:
This is a classic IT solution to the problem, but comes with a large number of disadvantages:
- Setting up VPNs is labour intensive and limits scalability.
- Adding clients is costly and time-consuming for third-parties.
- It creates a tight coupling on the IP protocol level.
- It will be hard to move your service to another region or datacenter.
- The third party clients are tightly coupled to the version of your messaging middleware, which makes:
- upgrades of the clients difficult
- migration to another messaging solutions near impossible
So is there a way to create a solution which uses standard internet technology?
The easiest way to implement an internet based solution is to use a polling web client, as shown in the diagram below:
This is standard and straight forward to implement event delivery, but has a number of other disadvantages:
- Inefficient: connections need to be re-established each time a polling request is received
- Unnecessary Load & Cluttered Logging: a great amount of polling requests will yield no new messages, which causes unnecessary load and logging
- Scaling is expensive: new clients will increase load disproportionately, which makes scaling expensive due to more hardware
The most famous alternative to polling is to use Websockets, as shown in the diagram below:
Websockets provides low-latency and low-overhead push support that can scale well. The disadvantages of Websockets are:
- REST semantic not supported: Websockets are like a low-level socket connection that does not impose any protocol like HTTP. Therefore, a custom message protocol needs to be defined, with all disadvantages thereof.
- Lack of documentation standard: No standard documentation tool like swagger/openapi is available for Websockets, so it requires a custom solution
- Complex Security: Authentication/Authorization requires a custom protocol, which is cumbersome in many regards: design, setup & documentation
- Flacky support: The Websockets protocol is often unsupported by the network services of the cloud providers.
Another well-known pattern for delivering events ares Webhooks, illustrated in the diagram below:
Webhooks are very efficient in notifying third-parties of events. The disadvantages of webhooks as a way to deliver events to clients are:
- More responsibility: Delivering messages becomes your companies’ responsibility: retry algorithms must be in place. If messages cannot be delivered you may have to figure out why.
- Time-to-Market: The clients will have to have an additional middleware component to which events can be pushed, which is time-consuming to set up
- Lack of common security model: the consuming party is in the lead of the security measures. If not agreed on/standardized every webhook can potentially have its own security specifics. Agreeing on standards requires interaction, which is time-consuming too.
The best way to stream events to a client is to use Server-Sent Events, as shown in the diagram below:
It provides a large number of benefits over other solutions:
- High performance: Offers low-latency and low-overhead push support that can scale well
- Simple protocol: initiated by a http GET, a SSE connection keeps the connection open, so that the server can push information (only), using a simple protocol containing: id, event, data. An empty data element denotes a heartbeat.
- Open: REST semantic fully supported: Since SSE are fully based on HTTP, it leverages the existing http infrastructure, like API Gateway, Authentication/Authorization mechanisms and documentation standards (swagger/openapi)
It is so open, that even curl supports it: You can watch a stream of events just by curl'ing to your endpoint!
The only disadvantage is that it is a relatively unknown.
If you need to implement an event stream to third party clients over the public internet, we highly recommend to use Server-Sent Events. It is a very efficient, easy to implement, adheres to normal REST semantics and has wide tool support.