Tag: local-first

I’m excited to review Hypermerge, as it was developed by the folks from Ink & Switch who wrote the Local-First Software article. It is designed as a fully peer-to-peer data storage system, and is electron/nodejs-only (no browser support).

The underlying data structure implementation, Automerge, is based the academic research paper A Conflict-Free Replicated JSON Datatype, and can be used independently – in fact there are a couple of different “networking” layers available – but Hypermerge is by far the most well-developed and “production ready”.

remoteStorage.js is a an offline-first solution that’s been around for quite some time, and stands out for having a formal protocol spec, first drafted in 2012. It would be really cool if it took off, but unfortunately there are only one or two commercial providers, and the only stable open-source server implementation is in PHP. There’s one written in rust that has been unmaintained since early 2018, and a nodejs one that has a big warning up top about being experimental & alpha-stage. Still, I figured it would be interesting to see how it stacks up according to my local-first database criteria. You can also look at the evaluation of gun-js to see how it compares.

Gun.js is an open-source project I’ve had my eye on for several years now, every once in a while checking back to see how it’s progressed, and whether the project I’m working on at the time is a good fit for it.

Gun stands out as one of the few players that’s actually delivering a peer-to-peer / decentralized system that works on a large scale.

Using my criteria for a local-first database, here’s how it stacks up:

I’ve been wrestling with the issue of “data storage that syncs and works offline” for a number of years now, and have gotten 80% of the way on a few different implementations, but always ultimately get stymied by the little things, like “how do I make it not break”.

Recently, I’ve been re-energized in my search by the wonderful Local-first software article by Ink & Switch, and then by James Long’s dotConf talk, CRDTs for Mortals.

So, you’re writing a destributed system local-first app, and you’re sending events back and forth between various clients and the server. One thing you’d really like to be able to do is determine the order in which events happened – this is important for the “last” part of “last-write-wins” CRDTs, for example. So you add a timestamp to each event as it’s created, and all is well.