(map make-poetry-line (take 5 (drop 3 (range))))

I listen to Retrowave / Synthwave / Outrun for that reason 🙂

Try Squarepusher for the “flow”.

It usually makes me feel small, with a sensation of a considerable weight put on my chest, and as if enclosed in an invisible container just looking at my screen with small POV and the sides of what I’m seeing blurred.

that sounds like a … terrible sensation :’)

Comes with some science attached to it https://brain.fm/science

Is it only certain types of commands or does it depend on the client which one? Like you have doFoo and want it on the client only on certain conditions, but you do eventually want all the FooResult on the server?

Only certain types of commands. For instance, I don't want clients to be able to execute create-user command without backend validation, but I do want them to be able to execute a create-todo. I'd like the client apps to immediately accept some commands, then generate events, then generate the corresponding local state (such as a datastructure for a TODO item). I want this to apply the original command on the backend once received, then if the backend generates a different event (e.g. conflict), the client to be able to rewind related events & replay them -- possibly asking for user input if the conflict can't be programmatically resolved.

^ I'm still clarifying this in my head, but it's roughly the flow that should happen... the CQRS+event sourcing resources I can find all assume you'll ship commands to the backend before clients receive state, but this would result in a poor client experience in the case of a mobile app. So I want to be able to "cheat" with a CQRS+ES equivalent of "optimistic updates"

If you just have all the added-todo events send to the back end it would be fine right, with some id to prevent duplication. I also struggle with 'proper' CQRS but it seems more complicated than needed for a lot of things. In the case of todo's it might even make more sense to send complete todosUpdated events to the server.

Sending the event may be the way to go -- not sure if sending the command is necessary other than just persisting it for the historical record. I'll keep working at it -- pretty sure I can tease out the right flow once I start adding tests & find which scenarios break

As an aside, I've seen a few sources claim full system CQRS+ES is an anti-pattern... I'm not convinced yet, but I'm convinced to find out 😉 IMO there's some interesting capabilities to be discovered here, especially as the command+event code is being shared between frontends & backends.

In https://github.com/openweb-nl/open-bank-mark I didn't let the commands get all the way to the frontend. But the GraphQL it uses is driven by commands + events. Might give some inspiration.

This is an excellent resource to parse through -- it'll take me a while, but thank you. I'm interested in exactly how the Heartbeat, Synchronizer, & Command handler is used in this setup... the system I'm building has an Onyx runtime to process commands from Kafka & a Datomic instance to power the frontends, so different pieces trying to achieve a similar effect