4

My company is planning to use CQRS architecture on our back-end but as a client-side developer I'm a bit confused about how to consume a request. Here are the methods that I came up with, none being ideal from my point of view:

  1. The server waits until the queue gets processed and gives back the needed data in the response. (sounds like a pretty poor approach from a performance point of view);
  2. The client makes the request and gets back a "202 Accepted" once the request was added to the queue, than the client uses an interval system to pool until it gets the necessary data from the back-end (I'm not a big fan of doing X http request every second);
  3. Web Sockets ... seems like the perfect solution as the server would be able to push the data to the client once it was processed (I'm a bit concerned about having thousands of sockets opened around the entire app).

So the question is: What is the best approach to this problem? (not necessarily one of the above)

Adrian Neatu
  • 1,989
  • 2
  • 19
  • 34
  • To complete vtortola's answer, you can also check this project [SwaggerSocket](http://blog.wordnik.com/introducing-swaggersocket-a-rest-over-websocket-protocol). It aims to provide a websocket interface to a REST API for better performances. – Sebastien Lorber Oct 07 '14 at 09:06
  • Thanks, we ended up using signalR(.net). – Adrian Neatu Dec 24 '14 at 10:37

2 Answers2

3

Well, it all depends on what you plan to do in the UI.

If you have a SPA and good understanding of events and subscriptions in Javascript, a single WebSocket connection seems like the most natural option. Thousands of WebSocket connections are not a problem in the server if the connections are idle most of the time, and the server is asynchronous (to avoid thread starvation). But then... why do you want a REST interface? you can send requests through the WebSocket with a correlation ID and then wait for a response with that same correlation id to know when it is done, this way you would avoid the overhead of creating new connections per each request.

If you are more comfortable with AJAX and want to use REST, then you can use this asynchronous approach, but you need to pool till you get the HTTP 303 See Other. It is not perfect, but it is probably better than opening a WebSocket only for the sake of that operation.

Blocking the connection till there is a response is a very bad approach. The network cannot be considered reliable, so if the connection cuts, the browser needs to know how to find out the result o fthe operation.

vtortola
  • 34,709
  • 29
  • 161
  • 263
  • Thanks, I decided to go with the websockets version because of the bi-directional messaging; it gives a lot of control. I hope it will scale well. – Adrian Neatu Jun 30 '14 at 15:07
0

Transport is not the only problem, how will you sync the contracts on server and client? I solved this with rendering all my Commands and Queries into a javascript. In my case I used t4 template engine but any template engine can be used. You can read more here

http://andersmalmgren.com/2014/02/05/typed-javascript-contracts-using-t4-templates/

As for transport I think REST is fine, if you use for example .NET WebApi and uses the async keyword correctly the framework will reuse the thread when ever there are I/O that is waiting (DB etc)

Anders
  • 17,306
  • 10
  • 76
  • 144