12

I have a web application that uses the jquery autocomplete plugin, which essentially sends via ajax a request containing text that has been typed into a textbox to our web server, once the web server receives this request, it is then handed off to rabbitmq.

I know that we do get benefits from using messaging, but it seems like using it for blocking rpc calls is a misuse and that something like WCF is far more appropriate in this instance, is this the case or is it considered acceptable architecture?

nickbw
  • 463
  • 1
  • 4
  • 12
  • Obviously it depends from your application, You can use the queue for the RPC calls,but I think it’s not its natural uses. In order to help you I have two questions: 1.Why do you use synchronous calls? 2.Do you have some problem with your current application? Anyway,I don’t know in which language you are developing the application but I think you could use the async-calls with RabbitMQ and use some technologies like Spring DeferredResult to get the results from your queue. I don’t like so much the synchronous calls, because you block the thread (for example during your DB search) uselessly. – Gabriele Santomaggio Apr 02 '14 at 12:18
  • 1. we have synchronous calls for the autocomplete plugin, you have to have to have a response for the request 2. no issue other than I think it's a misuse of messaging in this instance and I want to change it, and I am looking for evidence to support this change. – nickbw Apr 02 '14 at 21:41

2 Answers2

5

It's possible to perform RPC synchronous requests with RabbitMQ. Here it's explained very well, with its drawback included! So it's considered an acceptable architecture. Discouraged, but acceptable whenever the synchronous response is mandatory.

As a possible counter-effect is that adding RabbitMQ in the middle, you will add some latency to the solution.

However you have the possibility to gain in terms of reliability, flexibility, scalability,...

Sigi
  • 4,826
  • 1
  • 19
  • 23
  • yeah it's the latency that to me that is the deal breaker, you can't really have an autocomplete that is slow – nickbw Apr 03 '14 at 05:04
  • o well... latency here is measured in terms of millis. Faster is better, but that's not the only parameter to keep into account. The only thing that let me think, is that autocomplete should be implemented async. Interestingly, I have come across [this so post](http://stackoverflow.com/questions/4439953) - maybe it can be useful: I have never used autocomplete at now, I leave it to you. – Sigi Apr 03 '14 at 07:41
0

What benefit would you get from it? And in fairness if you put the message in the queue how is is synchronous? unless the same process that placed the message in the queue is the one removing it, but that is pretty much useless no?

Now, if all you want to do is place the message in the queue and process it later on is grand. Also the fact that you had WCF to the mixture is IMHO a symptom that something is perhaps not clear enough. You could use WCF as an API gateway and use it to write the message to the queue so this is not really about WCF or Queues, but more like sync vs async.

The way you are putting your ideas, does not look alright to me.

Asclepius
  • 57,944
  • 17
  • 167
  • 143
MeTitus
  • 3,390
  • 2
  • 25
  • 49
  • sometimes you have have to have to get a response from a message, for the autocomplete, if you didn't get a response it would be useless. I would prefer to remove synchronous calls from messaging and am looking for evidence to support/contradict this – nickbw Apr 02 '14 at 21:44
  • 1
    In asycn calls you get a response, but not the way you think. As an example, if you use CQRS with REST, when you submit an instruction such as: AddUserCommand, you only get HTTP codes such as 200, 401, 406.. nothing else, even if the message is processed sync. You need to use another API layer to retrieve the command status. That same layers (read models) is the same proving the data for your drop downs. One thing is for sure, if you want sync processing, remove the queues from your architecture. – MeTitus Apr 03 '14 at 07:16