I'm going to clone the main Redux repo, and then CD into the examples to-do MVC folder. Let's NPM install it, and run the dev server. Add a few to-dos, then reload the page. Oh, they're gone. I'm not entirely surprised by that, but let's see what we can do about it.
We'll install Redux Swarmlog and a few helper modules. We'll continue webpack to load JSON, and generate a pair of public/private cryptography keys. Swarmlog manages permissions by cryptographic signing.
Anyone with a public key can read our Redux store, but only those with a private key can write to it. Let's open up our index.js, and get hold of our crypto keys, and in the add Redux Swarmlog command. Now we can create a new distributed log by passing in a name, and a set of keys.
If we restart the server, reload our app, and inspect the page's resources, we find it has these two index DBs. The first is our to-do Swarmlog. We will use it to persist all the to-do actions that get dispatched. The second database is a lookup of all the Swarmlogs available in our app.
In a larger app, each collection may have its own Swarmlog, allowing us to assign different user permissions to the different parts of the store. Our next task is to update our actions. Each action can be associated with at most, one Swarmlog via its ID, which is a URL-friendly version of its public key.
Let's add the Redux Swarmlog ID to all our actions. Next, we go into our reducer, and set the initial state to be an empty array. We now need to configure our store to use Redux Swarmlog's middleware. This looks for all the actions that have a Redux Swarmlog ID, and appends them to the appropriate Swarmlog.
It marks each action with a session ID, so that it does not reduce local actions twice. Finally, back in index.js, we configure Redux Swarmlog to use our Redux store. It needs this so it can dispatch actions that come from remote sessions locally.
We go back to our to-dos app in the browser, and add some more to-dos. I'll just take it out of fullscreen, and refresh the browser. Our to-dos came back. What happened? Swarmlog wrote the actions to our index DB.
When the app reloaded, it looked in the Swarmlogs DB, to see if we had any Swarmlogs. Then, for each one it found, it reduced all the actions, thus adding our to-dos back into the Redux store, and updating the UI.
I've just opened an incognito window. Let's copy the URL across, and refresh the page. Wait for it. Yay! Let's cross off use Redux, add in some more to-dos, and cross off some more to-dos. Updates on both sides. Let's refresh the page. That works there.
Refresh this side. That also works. Let's turn off the server, and try deleting some more to-dos. That still seems to work. How's it working? You may have noted a small delay before the to-dos came in, when the incognito window loaded the app for the first time.
The browser was connecting to a WebRTC signaling server in order to find other peers with the data it needs. After the initial connection, updates are very quick. That's because Redux actions in the browser's index DB are being synced peer to peer.
However, if we attempted to connect directly to every peer, we would be limited to a couple of hundred peers. Swarmlog uses WebRTC swarm, a library which creates a network of peers, allowing them to communicate indirectly.
We can now scale globally. Let's have a look at some of the properties of a Redux Swarmlog application. React and Redux also syncs your UI, which gives you a really easy mental model for your UI updates.
Scale social apps for free, without the need for cloud, and low balances, and adverts. Cloud providers normally divide the world into five or six regions, but with WebRTC, if all peers are on the same network, data won't leave that network.
This gives you really low latency. Privacy, friends, not corporations, hold your data. Swarmlog will make it difficult for companies to index your data, but it's not good for sensitive information. If someone posts the public key on Twitter, everyone can read it.
Redux Swarmlog lends itself to live events, subtitles for the theater via mobile phone, or slideshows for a classroom. You don't want people faffing around with user accounts and passwords. You also don't want malicious viewers hijacking your presentation.
Public and private keys can be shared on a URL, and control who has read, and who has write access. Finally, devs are not responsible for user data. This is important for a couple of reasons. One, you don't want to be responsible for losing your user's data.
Two, if users store copyright information on your servers, you don't want to end up as the middleman in copyright disputes.