Skip to content

Event Handling

Date: 2018/02/20


  • message topics
  • reverse proxy support
  • security
  • Python clients
  • JS clients
  • multi-channel
  • easy to set up
  • future scalability



AMQP is a protocol for message communication. In the OSI stack, it is on the same level as HTTP/HTTPS.

This does add the difficulty that our current gateway (Janus) does not seem to support reverse-proxying AMQP.


STOMP is a further abstraction of messaging. RabbitMQ supports it using a plugin. It serves as a good abstraction for messaging, but still operates natively in its own protocol.

STOMP over WS?

Some libraries offer this. Advantages: we can reverse proxy. Disadvantages: what are we even doing at this point?

Don't reverse proxy?


  • We open more ports
  • Everyone needs to remember two hosts: the MQ, and the gateway
  • Two separate security implementations


  • We do not want outside clients to have a direct connection to the event bus implementation (RabbitMQ)
  • For service <-> event bus communication, AMQP is sufficiently generic.
  • Outside clients will need to subscribe to services offering data sources. This allows abstraction of the internal event bus implementation.


  • RabbitMQ is the chosen implementation.
  • Services are responsible for event bus interaction through functionality offered in
  • communicates using an async AMQP library. This implementation detail is hidden from clients of the API.
  • The event bus is not reverse proxied through the gateway
  • Clients outside the gateway will be able to subscribe to data sources offered by services. These services will be responsible for event -> data source translation.