- message topics
- reverse proxy support
- Python clients
- JS clients
- 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
brewblox_service.eventscommunicates 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.