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)
Best Answer
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.