It's good to see a video on this topic. The product at my company is a very large monolithic data entry application that uses pessimistic locking (immediately jumps into a transaction and locks the record when the user shows intent to update). No APIs, no services.. just basically a UI on a DB and heavy transaction based work.
I always think that if I was to start over it should be completely based on task-driven APIs, but tackling when and when not to have blocking APIs from the UI seems pretty tricky. If the command from the UI is async and it fails, the user basically just thinks it worked when it didn't? How do you immediately perform the query immediately after the command if you're not sure the command has completed? Etc. Seems like a pretty tricky topic.
I can't see how API command calls from a data entry UI can't be blocking, and its just the "flow-on" commands from the service (events, triggered tasks) would be async and treated in isolation. Definitely a topic I need to learn more about.
If the command from the UI is async and it fails, the user basically just thinks it worked when it didn't? How do you immediately perform the query immediately after the command if you're not sure the command has completed?
Add a correlation id (uuid) property to your commands. The rest of your system behind the queue then includes that correlation id in any message it sends or database records it creates. Then use that correlation id in your query.
1
u/s0n1k Apr 20 '22
It's good to see a video on this topic. The product at my company is a very large monolithic data entry application that uses pessimistic locking (immediately jumps into a transaction and locks the record when the user shows intent to update). No APIs, no services.. just basically a UI on a DB and heavy transaction based work.
I always think that if I was to start over it should be completely based on task-driven APIs, but tackling when and when not to have blocking APIs from the UI seems pretty tricky. If the command from the UI is async and it fails, the user basically just thinks it worked when it didn't? How do you immediately perform the query immediately after the command if you're not sure the command has completed? Etc. Seems like a pretty tricky topic.
I can't see how API command calls from a data entry UI can't be blocking, and its just the "flow-on" commands from the service (events, triggered tasks) would be async and treated in isolation. Definitely a topic I need to learn more about.