Skip to main content

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
Asked
Viewed 3k times
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.

1

3 Answers 3

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 ;)

1
  • 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
    –  Skirek
    2021-07-19 23:10:08 +00:00
    Commented Jul 19, 2021 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.

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

1
  • Yea a lot of these are what I was thinking as well. I'll stick with the REST API in front. Thank you.
    Skirek
    –  Skirek
    2021-07-19 23:10:57 +00:00
    Commented Jul 19, 2021 at 23:10

Your Answer

Reminder: Answers generated by AI tools are not allowed due to Software Engineering Stack Exchange's artificial intelligence policy

Post as a guest

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.