Blog

How to expose events to third parties on the public internet

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?

Polling

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

Websockets

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.

Webhooks

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.

conclusion

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.

Explore related posts