|
|
|
|
|
|
by rabbitmq
5917 days ago
|
|
|
Hi, Alexis here from RabbitMQ. Wtf? You may not like what we do with AMQP but I can assure that lots of people are very happy using it in its RabbitMQ incarnation. Which version of AMQP have you "had the misfortune to work with" and how have you found it "hopelessly overengineered"? Is there something else you would recommend - and if so why? We do actually like making our product better and appreciate constructive criticism. Please do explain. Also please note that RabbitMQ supports multiple protocols and one reason we like AMQP 0-8 and 0-9-1 is that they are flexible enough to make this easy (see e.g. RabbitHub on Github). Cheers alexis |
|
|
Well, I'll try to elaborate on my rant. Most of it from memory (been a year ago since I last touched AMQP).
Back then when I looked at AMQP (and used it for one project):
* It was very hard to find reasonable documentation. The most accessible I found was the (excellent) http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ blog post. This was what eventually got us off the ground. Imho a testament to the shortcomings of the "official" documentation (where is it?).
* RabbitMQ only implemented AMQP 0.8. I cannot remember the exact differences between 0.9 and 0.8 (and heck, good luck trying to find a document explaining them even today). For us it boiled down to some clients simply not working and it took a while to figure out what the problem even was.
* Client interoperability was generally spotty, even in clients supposed to be compatible. It seems the idea of that whole spec-file stuff was to make the protocol pluggable and flexible. However the only thing it seems to have achieved is to make client development hell. The client we eventually went with (py-amqplib) doesn't even use the spec-file because "parsing takes too long".
* Moreover the sheer existence of http://www.rabbitmq.com/interoperability.html is a testament to a flawed protocol. If I can't rely on a 0.8 client to talk to a 0.8 server properly, then something is fundamentally wrong.
* There's a huge pile of semantic baggage (Exchanges, Bindings, Queues, Channels) that left us with a giant "WTF" the more we used it. Yes, it can be made work. But hell, talk about overengineering. Much simpler constructions could have been used to achieve the same goals.
* As I just learned during my googling for this post, apparently some of the problems have even been acknowledged by the officials and are supposed to be simplified in AMQP 1.0 (http://www.amqp.org/confluence/display/AMQP/Background+to+AM...). But I'm not expecting much, to be honest.
So, that's just a few points that popped into my head immediately, there's more if I'd dig deeper. It's just a fundamentally bad protocol if I have ever seen one, and I'm honestly surprised to see people defend it even after the creators themselves (iMatix) acknowledge it to be a dead-end.
To put it from an different angle: When you think about what AMQP really does then how long would it take you to whip up a near-trivial but feature-equivalent protocol from scratch? I could think of many ways to skin that cat in a better way, with a simple, hackable, plain-text protocol.
You know, one of those protocols where I, as a developer, can even sniff and see what is going on at any time. Those are possible, as demonstrated by redis, memcached, STOMP, beanstalkd and many others.
I acknowledge that some complexity is unavoidable for advanced use-cases. Still, a good protocol layers the complexity in a way so that simple stuff remains simple and complex stuff becomes manageable. To me AMQP is a complete failure in both regards; you are confronted with the full complexity even for the most trivial use-case. And it seems for complex use-cases it adds a hefty layer of complexity of its own, rather than helping to wrap up.