7

I have a large customer facing web applicaton (.net mvc if that matters) that I need to split down to a number of services. Some of these services will then be shared with other applications.

At the moment all of the servers I have are part of a web cluster that we use for this app, though this may change in the future.

What I am struggling with is deciding between learning a Message Queueing system such as RabbitMQ, which should improve performance, and will run over tcp/ip, making it possbile to take some of these key services away from the web server cluster, and carrying on with creating an internal JSON / REST API. (Which we are already familiar with, but will not help improve performance.)

However, being as RabbitMQ Queues are one way, I would then need to come up with a strategy for handling occasions when the website / user needs feedback from one of the services. Which means some way of creating a session specific return message queue, or relying on RPC, which may then impact on performance.

To my mind RabbitMQ gives me more flexibility and opportunity (I can move code off web servers, manage message queues and so on), but also creates more risk as its unknown to the business, and means that not only are we splitting our application up, but we are adding in a new communication method.

So, has anyone implemented RabbitMQ in a web based scenario like this, and if so, do they now regret it, and wish they had stuck to using REST? (Or vice versa)

  • Message queues are not suitable for synchronous communication. Is your communication sync or async? Two-way is also awkward with queues and very natural with RPC. – usr Jun 6 '16 at 11:30
  • I can see both types of communication being needed; Probably more 2 way than one way, so I can give feedback to the users. – Matt Jun 6 '16 at 11:42
  • So it's synchronous two-way? What would a queue gain you there? – usr Jun 6 '16 at 11:47
  • Nothing in the 2 way messages, I am just trying to establish a consistent method of service communication. It looks like Rest/WebAPI may be the way to go for now, and then investigate RabbitMQ when I can identify a solid set of services / methods that would benefit from it. – Matt Jun 6 '16 at 12:20
  • You could even make everything RPC based and use queues internally. The RPC endpoint would queue and dequeue internally. Make queueing an explicit concept in the RPC API if required. – usr Jun 6 '16 at 12:21
4

RabbitMQ can be used for RPC. For more information, see RabbitMQ in Action: Distributed Messaging for Everyone by Alvaro Videla and Jason J. W. Williams: section 4.3: RPC with RabbitMQ, page 80.

This being said, you don't really have to make a choice between a message queue service and REST/SOAP. Both can be used, and some services can expose both interfaces.

Note that there are a few benefits of providing REST/SOAP interfaces consistently over all of your services:

  • In some languages, using AMQP may not be particularly straightforward. A few years ago, it was practically impossible to use AMQP with Python 3. I tried. And failed. Today, it's relatively easy, but what will happen when Python 4 will be released? Some other languages may have either no or only badly implemented AMQP clients, making it painful to communicate with RabbitMQ. REST, on the other hand, is much more popular and have a better chance of having good libraries in more languages.

  • Exposing AMQP to the public may not be an easy thing to do, especially when it comes to configuring secure accesses, API keys, etc.

  • Much more developers have a professional experience consuming REST APIs than communicating through AMQP.

  • one way to avoid the MQ interop problem is to use one designed to be neutral - like ZeroMQ. – gbjbaanb Jun 6 '16 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.