2

Currently working on designing an application that will take in JSON data from remote client applications. The data these client applications are sending is going to go into a Message Broker, namely RabbitMQ, to be later processed. In the architecture, I cannot really decide if the client application should send directly to Rabbitmq over ampq or if it should hit a REST API and then the REST API sends it to RabbitMQ.

The extra step of the REST API seems unnecessary but I'm not quite sure if RabbitMQ should be publicly accessible. Security and stability being the main concern.

A few key notes about the client application:

  • Will be thousands of them (think IOT) all over the world
  • Will access either RabbitMQ or the REST API over the internet
  • Will not be in networks that I control

Appreciate the insight.

Skirek
  • 21
  • 2

3 Answers3

3

If I were you, I would use a REST API. This has several advantages:

  • Less stateful connections. Every REST-Call is stateless. having thousands of clients, you don't have thousands of open connections.
  • Better access control with more fine-grained permissions
  • Generally more widespread. In the IoT environment you probably have less of the problem, but AMQP is not known everywhere. On the other hand, hardly a developer in the last 15 years does not know REST.

From a security point of view, I would not have any concerns about AMQP. Regarding stability, I have no experience with connecting several thousand clients. personally that would scare me a little ;)

Sn0bli
  • 541
  • 1
  • 4
  • 7
  • That makes a lot of sense. I think I will use a REST API in front. REST being synonymous with HTTP(S) allows me to avoid firewall rules. Appreciate your thoughts. – Skirek Jul 19 '21 at 23:10
1

I can't see why your RabbitMQ broker have to be publicly accessible just because you're sending your payloads directly over the AMQP protocol. You could have your clients authenticate with user/pass and use TLS to connect.

Johannes Nordangård
  • 11
  • 1
0

I think its best to hide the queue endpoint with an API.

There are a number of things to take into consideration and I am not sure that RabbitMQ can handle them all.

  1. Authentication - will you need to manage API keys?
  2. Validation of the message - how will you stop badly formatted messages?
  3. Rate limiting - What if a device goes crazy and you want to drop its messages?
  4. Sign up portal - Do you want people to be able to register an account?

Generally these are problems solved by API Gateways, so an off the shelf one plus a simple http -> rabbit api endpoint will give you a lot of stuff without much worry or effort

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • Yea a lot of these are what I was thinking as well. I'll stick with the REST API in front. Thank you. – Skirek Jul 19 '21 at 23:10