Brewblox

Appearance

Event Handling ​

Date: 2018/02/20

Requirements ​

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

Considerations ​

AMQP ​

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 ​

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? ​

Consequences:

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

Conclusions ​

  • 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.

Implementation ​

  • RabbitMQ is the chosen implementation.
  • Services are responsible for event bus interaction through functionality offered in brewblox_service.events.
  • brewblox_service.events 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.