The Roundtrippinig (fulcro) Mutation
I am writing another iteration of my fulcro app. I now have a datascript db running in a webworker that keeps a websocket connection to the server which pushes mutations to clients. This brings me to a new conceptual look at mutations.
Command Query Separation
Until now I saw the difference between pulling data from the webserver to the browser and via cache to the UI and transacting changes, what fulcro calls mutations, from the UI to the server.
I also had my server keep subscriptions of what a client had pulled, to push updates to clients, to update their caches.
I saw these as one UI to one Server and one Server to multiple UIs communications respectively.
New Conceptual View
With the web worker caching the (almost) whole server database the server does not store subscriptions but keeps all workers up to date when something changes. This changes the whole picture.
Pull
A worker pulls, or caches, everything, once from the server, then it is kept up to date. So the normal pull, or query, is from the browser to the worker.
Mutations
A mutation now starts at the UI, gets forwarded to the worker, gets forwarded to the server, gets pushed to all workers, gets messages to all Windows and Tabs.
Push
So the push, as a separate thing, goes away.
The new Round Trip Mutation
This changes the concepts in my head. The mutation is now the central round tripping thing. Everything else, including the databases in the server and in the workers, is just cached state.
- The Mutation is now the central thing which is persisted to the mutation-log and can be replayed.
- Admin can originate mutations on the server.
Applicability
This makes sense because my data is all domain data, abstract, administrative information. It is the same in the databases and in the ui.