Ask HN: Should I use AMQP RPC for simple requests?
1 comments
In general, you want any UI actions (like saving a form) to be as fast as possible and any feedback to be immediate.
While writing to a queue is fast, retrieving a response from a queued message requires waiting for the message to be processed, and waiting for the feedback message from another queue where the response gets queued.
As you can probably tell, this gets really complicated really fast. So queues are really good for one way, asynchronous communication, but pretty poor for synchronous communication. It can be possible to make this all work very fast, but the added complexity for simple UI flow may not be worth it.
REST will be a better choice here, since response codes and status messages are easier to work with.
While writing to a queue is fast, retrieving a response from a queued message requires waiting for the message to be processed, and waiting for the feedback message from another queue where the response gets queued.
As you can probably tell, this gets really complicated really fast. So queues are really good for one way, asynchronous communication, but pretty poor for synchronous communication. It can be possible to make this all work very fast, but the added complexity for simple UI flow may not be worth it.
REST will be a better choice here, since response codes and status messages are easier to work with.
I thought that may be the case but reading about synchronous communication through the queue and a desire to keep the architecture simple with a single api was causing me doubt.
When I read about AMQP RPC it sounds like this would WORK for this kind of task, but is it the smart thing to do for such a use case? Am I making it more complicated than it should be and should use REST + AMQP depending on task?
Any comments would be greatly appreciated!