How to handle CQRS from a client-side perspective

Question

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

Answer 1

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)

Answer 2

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.