Immutability, Persistence and History
+overview
This presentation makes a general case for these attributes of a data system. This thinking is from javascript work at Facebook as embodied by React, Flux or Reflux, but I think the underlying thinking about data system properties feels very closely related to core concepts of the card system implemented in wagn.
In the long run, we should be looking at these specific tools for the front end, but that can wait. Two archetectural concepts that have come up lately are more connected to how we should include these properties in the back end. At first I was thinking that making a clear split between the Card model and the history module was to allow us to skip all that work if we didn't need to refer to state before the current version. Now I'm thinking that the representation of the current state as the result of a flow of actions The cards and card_references tables can be re-generated if you have a store of the history. In fact, with the complete history, you can restore any state of the data, or compare them or ...
+needs
To have changing a deck (some cards) and history abstracted from rendering and representing current state. Now that History is more of a module and change processes are all tied together and organized by the event system, I think the main idea here is to split rendering from a stream of changes represented as changesets. With events the code can be configured with the current History system as module, and/or a second system that encodes updates as a stream of changes. I'm going to leave the original +needs text below for now and try to evolve this idea into something more sensible.
I have been Slacking in other workspaces and brainstorming about federated content architectures and I came across a project called ValueFlows that is now defined on top of a W3 standard for ActivityPub (I can edit in the links later). that is used for a lot of new OS social media tools including Mastadon. The idea here would be to define the necessary ValueFlow specifications to transform Card change events into VF events. This can use something based on our YAML representation of card hands (subsets of a deck) for packaging cards in modules libraries and updates. There is an implementation based on JSON, but serialization formats can be fungable as needed for the context.
This wplit was also something to be considered for Decko instances that might experience extreme scaling and need to deliver data at Wikipedia rates. Having a read-only front end and caching all the renderings of that state. Systems engineering issues are better if the systems are designed as flows of events in a larger system, and the event system driving the AR based tables of actions, acts and changes IIRC that are used now to render (and edit) from revisions.
Old text below:
Instead implement a Store abstraction similar to the one used by Flux or Reflux, only instead of being a persistant store in a browser, it can use a storage model (active record to start). The key to this abstraction is that you never mutate a card directly, you send the update payload down the line in a change action to the Stores. Listener/observers to the actions and the resulting Store transformations signalled to downstream listeners trigger all the other changes and events that need to happen. Otherwise, the stores are 'get-only', you can only read data or push payloads at the store.
This would allow us to persistently cache objects. In a lot more places we would have to carry the equivalent of action_id for card_ids so that we don't have to break the cache when rules change. Any cached data whether in AR or a cache store would have the persistant and immutable properties. New data will have new action_ids to be cached or stored, but all these ids are internal to the store anyway. Memory and cache instances of an abstract card will be made concrete with an action_id (except when new?).