In Flux and SSOT, Store is not the Truth, Actions is!
The title is too short to write down my whole sentence, I wanted to say the Actions with the initial state of a Store, is the Truth in the term “Single Srouce of Truth”.
Usually we talk about MVC, while “Model” is the centeral part of an MVC app. However, recently I found it not true in Flux, during learning Redux library and reading the post it recommanded about Apache Kafka. Now I believe Store is more like a DataView of a initial state and its actions, rather than the Model in MVC. Let me explain why.
About Kafka
Before I dig in, I want to recommand three articles on Apache Kafka, a distributed system designed for streams. They are talking about Database, but as a lot to do with designing realtime apps:
These posts introduced some ideas on logical logs, which Kafka uses to recover or replica databases in distributed systems. I found the ideas on logical logs is very useful in understanding Actions in Flux apps.
Time Traveling Debugger
Since Elm introduces Time Traveling Debugger, people are becoming amazed by its clever solution on replaying actions. Now it comes to React with Redux. The core idea of a Time Traveling Debugger is to record the actions, and replay them on need. A developer may operate on the actions to go back and forward in time to reproduce the states.
The Store in Flux, contains all the data an app needs, is always generated from the recoreded Actions. The Store is not a Truth which is consistent and remains during the time, but rather generated from Actions, while the Actions never change after created.
Merge operations of users
There’s another case in realtime collaborating apps, like online documents which support multiple-user editing simultaneously. Due to the delay between a server and its clients, it’s hard to keep them synced in every second.
Instead, every cilent would hold its own copy of the document. As the user editing the document, an operation is applied to the document. After the operations from other users is pushed from server, all the operations will be merged into a stream to produce the latest version of the document.
In this case we also find the Store of the document is not the Truth, it’s changing over time, and heavily influenced by the delay of the network. While the operations is now the most important piece that generates the document.
Inital state and Actions is the “T” in SSOT
Then we go back to Flux, suppose we are debugging the actions, suppose we are sharing data across many clients, we will probablly get different part of all the informations and meanwhile get different Stores. Stores are produced based on different combinations of actions and an initial state. In the end we will found Actions and the initial state is the essence of an app. Then it can be called “Truth”.
Influences on Data Stores
As the posts on Kafka introduced, logical logs which is like the logs of all database operations, is widely used in recovering after crashes, and replication among distributed databases. And sure it works well.
In creating realtime apps, with React or whatever, we are facing the same problem as Database technology faced. We need to sync the data of the GUI among servers and clients, and hope there is a Single Source of Truch that helps us make sure of consistency. I think the researches on Kafka just showed the solution.
Record Actions
Last night when I was learning about Redux, I find the core of Redux DevTools is simple and I started to replicate one in my own code, and it works:
Soon I found it’s quite fun we can just record all the Actions and apply operations on the Actions for different purposes. One idea of mine is to combine this idea with Cumulo and maniputes the Actions recorded on a server. I think it can be fun too.
That’s it. You may reach me on Twitter if you want to talk about this idea.
