5 ms·
I understand and partially agree that AMQP is a bit complicated. Much like XML is a complicated version of JSON. However, I can personally vouch that this 'c
by revoltingx 16y ago
I understand and partially agree that AMQP is a bit complicated.
Much like XML is a complicated version of JSON.
However, I can personally vouch that this 'complexity' once somewhat mastered can be used to create messaging schemes in no time.
What's so complex about it? You have exchanges, queues, and bindings.
With a bit of practice, it's fairly simple to grasp the concepts.
"AMQP is quite unusual in that it starts low on the stack, building on protocols like TCP rather than HTTP"
This person has obviously never built anything truly high performance. Using HTTP would add a lot of latency, and he complains about message speed?
Sure 0MQ is the fastest, but with RabbitMQ you get <1ms latency.
"People who today read the AMQP specifications tend to make one main complaint: the protocol is too complex."
I wonder how many of these people actually use it.
He goes into a bunch of useless analogies but doesn't actually discuss WHAT'S complex about it.
(Usage wise, NOT implementation wise.)
A protocol doesn't HAVE to evolve. JSON being an example.
But, in the end, AMQP isn't perfect, but it can still be used to build good software.
This person knows very little about building messaging software, and he admits it himself.
I'd take his complaints with a huge grain of salt.
You can use something like protobuf to get really fast de-serialization if you really want encoding.
- defen 16y ago> This person knows very little about building messaging software, and he admits it himself. I'd take his complaints with a huge grain of salt. The author of the article is the main author of AMQP/0.8 and OpenAMQ, and the founder of the company that produces ØMQ.
- revoltingx 16y agoWhich surprises me given those comments. He himself admits not to be a messaging expert.
- heresy 16y agoHe's being humble.
- revoltingx 16y agoWell, he makes a LOT of false or illogical statements in this article. Not something I'd expect from someone like that.
- evgen 16y agoIt would not be much of a surprise if you had watched this unfold over the past couple of years. The 0MQ guys lost the AMQP fight and apparently decided that they would instead pivot to fast & lightweight, but non-durable, queues (and whine to anyone who would listen about how AMQP sucks now that they are no longer a part of the effort.) These ephemeral queues have gained a lot of attention recently for simple pubsub, job queues, and other misc tasks in the application stack. Unfortunately they pivoted right into the redis steamroller. Sucks to be them, but as the saying goes: "karma's a bitch..."
- aaronblohowiak 16y agoAMQP's scope is too large. STOMP or 0mq give most of what's good without all the bloat, and you can handle brokering, exchanging, transformation &etc with your applications resident on the bus.
- revoltingx 16y ago0MQ is not a protocol as far as I know, it is an application. It's unfair to compare it to AMQP. STOMP is not flexible enough, but it is pretty good.
- aaronblohowiak 16y agoIts protocol is undergoing definition: http://rfc.zeromq.org/ http://rfc.zeromq.org/