how to get client UI updates from read model in a CQRS+ES system

[Hajdrik Attila]

We're just getting more familiar with the CQRS pattern and an interesting question emerged. After some digging it seems that CQRS+ES separates reads and writes in such manner that there is basically no way for the client app to know that a command has finished and the read store has been updated.

While this leads to a much better performance and allows for creating highly scalable architecture we believe that the UX will suffer on another point. (It's like writing a comment and telling the user that it will be displayed later at some point in the future and let him do the pushing of the refresh button)

The question is:
Do you think we can rely on something like web sockets to get notified when the read store is updated? For example a user calls the newCustomerCommand and after the read datastore is updated a customerListChangedEvent is sent to the client to know that there was a change. What is the best practice here? How do you think these scenarios should be handled?

Thank you for you answers!

[Marijn Huizendveld]

It depends really. It's all about educating users. In some cases you might want to trick the user into thinking it has been updated already, in others your users might not even care and it's mostly you, the developer, that thinks it should be updated. Go talk to your domain expert and find out when this data is required and why…

P.s. in the CQRS class video by Greg on Vidler there is a section dedicated to tricking users...

[Kijana Woodard]

It depends. :-)

There's web sockets, long polling, etc when you really need a response.

For comments, you could fake it. Manipulate the dom and put their comment in the list.

For a 'place order' button, you display 'thanks, we'll email you status'.

There's also just doing crud where it makes sense.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonathan Matheus]

You don't have to push the command to a queue to be using CQRS. You could have totally synchronous command processing. However, there are benefits to using queuing with CQRS. They do make synchronous views harder to deal with.

Web sockets or a framework on top of it, like signalR is a great way to go if you need push responses to the client UI. Where you integrate depends on why you're using it. If you're using it for a view that depends on a specific view model, you might want to send an infrastructure message from the view demoralizer after you process the event. That increases the likelihood that the view model will be up to date when the client queries the model.

If you can get away with "faking it". You could have an event handler that sends the web socket or SignalR message containing whatever info the client needs to populate the model client-side without depending on querying the view again. The event handler and view denormalizer would process in parallel if using pub sub, so there's no guarantee that the view denormalizer has processed the event when the message is sent to the client. This can lead to odd behavior like the user refreshing the page and losing the created view model, but in many cases its not a big deal & it saves a query to the server.

Jonathan

<Screen Shot 2013-01-28 at 3.36.19 PM.png>

[Péter Podoski]

You could query the server by the command id to check its status. If handled successfully, redirect to the list, if there were errors, show those by selecting the errors attached to that command id, and until it is completed show "please wait" & poll every X seconds. Of course you could use WebSockets (SignalR as mentioned is a good choice) but you might eventually find yourself being enprisoned in technologies far away from the real domain problems. 

I know the "new customer" scenario was only an example, but DDD allows you to dig even deeper to a point where you can ask the experts about what should happen when a complex command is being processed. This scenario/context seems not enough complicated to worth the effort in implementing such an infrastructure. I suggest you to discover the possible BCs in your project and select the appropriate tool implementing them. It is bad to throw away CQRS and switch back to some scaffolded app, when you find the real complexity. :)

The "new customer", "add comment" command can fail so rarely that you are even OK if you fake the update. However, if you have a more concrete scenario, feel free to drop it in here. 

pody

--

[Hajdrik Attila]

Thank you all for the valuable response, you just confirmed what we've in our minds. Of course the New Customer is much more a CRUD like operation, but we all can "abstract" it to make it fit into a CQRS environment :-)

Of course the UX and the interaction design should be driven to make such async update scenarios easy for the user. For example if the user is sitting in front of a list then that list should have a manual refresh option and an "auto refresh" toggle too. It depends on the concrete user scenario.

Thanks,

Attila & Zoltan

[Hajdrik Attila]

Thanks for the video link, I did not see that before :-)

From: Marijn Huizendveld <marijn.hu...@gmail.com>
Reply-To: "ddd...@googlegroups.com" <ddd...@googlegroups.com>
Date: Monday, January 28, 2013 4:09 PM
To: "ddd...@googlegroups.com" <ddd...@googlegroups.com>
Subject: Re: [DDD/CQRS] how to get client UI updates from read model in a CQRS+ES system

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group, send email to dddcqrs+u...@googlegroups.com.