What do you use to
accomplish this? We are currently using Asp.net Core Web API and web sockets.
ServiceStack and Server Sent Events since updates are only needed 1 way but your way works fine too.
In my case my read model applications send update messages through RabbitMq which serverstack receives and queues for updating the clients at predefined intervals.
Oh, also in my solution when a read model is updated by another client all clients get the update - which wouldn’t happen in the GET Retry-After situation
Oh, also in my solution when a read model is updated by another client all clients get the update - which wouldn’t happen in the GET Retry-After situation
One of the other ways
we use web sockets is for the other users that have the same lead screen open,
we send them the update as well. When a user loads the lead screen it
registers with the web socket system for that lead id and then when an update
to the read-model occurs we inform all registered clients.
With all the information,
you have all provided we are looking at maybe adding a backup system that uses
“GET Retry-After”. We are still a little leery of relying solely
on web sockets.
How
do you deal with commands that produce many events? Send the last one?
Also, when
updating the read-model, which in my case there is one materialized view, it
only has the latest version/event/log id. If you polled with the “GET
Retry-After” and some other process updates the stream with another event,
then you could miss your windows and never get that version of the materialized
view. Do you say version => then the
one returned? Do you create many materialized
views / read models?
FWIW, we are doing what has been described here (execute command, return new position, poll for read model to catch up with position) but in a server side REST facade to our services consumed by a JavaScript UI.
We get a CQRS architecture and decoupling, client gets a traditional REST api with the expected synchronous semantics.
Of course this depends on your particular solution, but I think you would only need to wait until your customer read model is updated. I would guess this is the one you want to display immediately after customer is updated? Any other views that show, for example, customer lists could be updated asynchronous with web sockets, but in my view these views are usually not as important to have immediately up to date.