Thanks a lot for the feedback. Not every side effect requires two round trips to the server. The command to mark a todo-item as done for example, does not need any additional input. Therefore the db-view for the todo list already returns an encrypted command for each todo-item. Sure, you still have 2 requests, but the first one was to fetch the db-view normally.
If the user is not allowed to mark a todo-item as done, your server just omits the corresponding encrypted command entries and the UI can react to this by disabling or removing the corresponding button.
If the client has already issued a command, why receive the actual encrypted command map then send it back? Why not validate, send result of validation to client for optimistic update purposes, but also directly process in the server?
Using the command approach is not a requirement to use db-view. You can for sure also build other API endpoints which directly process the command if it is valid.
However I noticed during the development of the first prototype that the validation itself is a read-only / “pure” operation. But it is most often intertwined with an API endpoint that does side-effects. Therefore I moved the validation over to the read-only / “pure” part of the API.
Last week I also found a very interesting example of LiveView in Clojure:
If you like to dive deeper into these topics.