I am working on a new project with the above
technology. I am deep in the weeds at
the moment and have some questions that some in the community might have
already grappled with.
Note: The application
we are building is similar to standard CRM.
We are also using Docker Swarm, so we cannot ensure the same server will
handle any given request, except for the microservice handling the web sockets.
Updating the UI
How are you guys keeping your single page application screens
updated after commands are completed? How
are you handling commands that fail?
Our pattern currently looks like this. https://i-msdn.sec.s-msft.com/dynimg/IC709550.png.
I am currently focusing on lead screen and the UI is designed to keep the same
screen up when the user issues a command.
I cannot close the screen after they issue most commands. I have seen many examples where developers
close the screen afterwards and the refresh a listing. This is not an option for this screen. Once a command is sent, the UI, in most cases,
needs to lock, then wait for the outcome.
Example Commands and Events
- Update Status - > Event – Status
- Update Document -> Event – Document
- Resume Lead -> Event – Lead Resumed
Do any of you use web sockets to inform the SPA screen that
a new read model was updated after a successful command? When the command fails send another message? Is this reliable?
(note: this is our current thinking, but
we are nervous to rely entirely on web sockets)
Do any of you use a correlation id and periodically query
the event store to see if the command was successful? This seems wrong because you are unduly
taxing the event store, where I think you should be query a separate read-model.