How to expose events to third parties on the public internet

08 Jun, 2022
Xebia Background Header Wave

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.

Direct connection

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
  • Not common for B2B: Websocket are commonly used in browsers by means of javascript. In a B2B context, which generally involves other languages than javascript, Websockets can be a technical burden for third parties unless a SDK is offered.
  • 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.

Server-Sent Events

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.

Mark van Holsteijn
Mark van Holsteijn is a senior software systems architect at Xebia Cloud-native solutions. He is passionate about removing waste in the software delivery process and keeping things clear and simple.

Explore related posts