automerge-rs VS SyncedStore

See also, Autosurgeon (with a 0.3.0 release today), which is a higher level API on top of Automerge for Rust:

I'm building a mobile app with a server backend, and I was looking for resources to build them in an offline-first way (since unlike on the browser, people expect to use apps offline, if they can, such as fitness or habit trackers).

I found the concept of conflict-free relational data types (CRDTS) interesting as it allows you to have fully offline experiences while also having a conflict-free syncing experience. I was looking for some good libraries and came across automerge [0] and yrs [1], but both had some rough APIs as they're primarily low-level Rust libraries that are wrapped by higher-level TypeScript APIs.

Autosurgeon wraps the low-level API of automerge to make it much more ergonomic, closer to the TypeScript experience, but in Rust of course. You can for example use `struct`s which autosurgeon will serialize and deserialize automatically, which is not present in base automerge, which focuses more on string keys and arbitrary values.

I am planning on using this together with Flutter and flutter_rust_bridge [2] in order to use this same Rust library everywhere. In this case, the server just becomes another (albeit more privileged) client.

[0] https://github.com/automerge/automerge-rs

[1] https://github.com/y-crdt/y-crdt

[2] https://github.com/fzyzcjy/flutter_rust_bridge

I found the concept of conflict-free relational data types (CRDTS) interesting as it allows you to have fully offline experiences while also having a conflict-free syncing experience. I was looking for some good libraries and came across automerge and yrs, but both had some rough APIs as they're primarily low-level libraries that are wrapped by TypeScript APIs.

Yes, the plan is to use PostgreSQL. I had a discussion with one of the devs in this ticket about the strategy for this.

In any case, my current plan is to use Automerge for the data handling itself (so I can easily do collaboration), but that crate doesn't handle on-disk storage. For this I need another solution, and a K/V store is well suited for this task.

15 years working in software, Rust has been my favourite language for the last 2. Recently completed a contract to prototype a distributed Tailscale-inspired VPN built on Ink and Switch's CRDT project automerge-rs.

Complex topic. There's a very easy-to-use CRDT library for Rust (automerge), while there isn't much support for operational transforms (although Aper is new to me, I have to check it out).

I've been watching automerge-rs like a hawk, because they seem to be the only CRDT implementation where you don't need a Mathematics master to understand how to use it. They've been working on a rewrite for the last two years, hopefully they'll do a new release soon.

https://github.com/automerge/automerge-rs

By the way despite that particular repo (@localfirst/state) last being touched 6 months ago, Herb Caudill definitely seems still active in this space (I believe he's been working on other parts of this more recently -- e.g. ideas about authentication), and I think automerge development itself is quite active right now leading up to a 1.0 release which seems fairly imminent, for which a lot of fundamental work has been done, also coordinating with automerge-rs.

This article has been quite the inspiration for many projects and progress on this front. I think we're seeing more and more developments around CRDTs and local-first frameworks / applications.

I'm working on a few projects in this area:

- https://www.typecell.org - Notion meets Notebook-style live programming for TypeScript / React

- https://www.blocknotejs.org - a rich text editor built on TipTap / Prosemirror that supports Yjs for local-first collaboration

- https://syncedstore.org - a wrapper around Yjs for easier development

In my experience so far, some things get more complicated when building a local-first application, and some things get a lot easier. What gets easier is that once you've modeled and implemented the data-layer (which does require you to rethink / unlearn a few principles), you don't need to worry about data-fetching, errors etc. as much as in a regular "API-based" app.

Another interesting video I recommend on this topic is about Linear's "Sync Engine" which employs some of the local-first techniques as well: https://www.youtube.com/watch?v=Wo2m3jaJixU

Hi! Great questions :)

First of all, SyncedStore does not implement any CRDT algorithms. Credits for this go to Yjs [1] (and its author Kevin), which it uses as underlying CRDT.

Yjs and Automerge are (afaik) the two most commonly used CRDT implementations. Both have their pros and cons, but Yjs has focused a lot on performance [2].

Automerge has a bit friendlier "Immer style" [3] API. I'm not too familiar with @localfirst/state, but it seems to add a Redux style API on top of Automerge.

My approach with SyncedStore was really to provide an API on top of Yjs that's as simple as possible to use in React / Vue / Svelte or plain JS app. I.e.: only use a single React Hook to observe changes, and use regular Javascript assigments to update values. The API is inspired mostly by Reactive Programming libraries such as MobX [4] (from the same author as Immer).

Hope you're still following along :) Maybe it helps to compare the TODO-MVC applications, as both SyncedStore (https://github.com/YousefED/SyncedStore/tree/main/examples) and @localfirst/state (https://github.com/local-first-web/state/tree/main/examples/...) have implemented these as examples!

[1]: https://github.com/yjs/yjs

I’m exploring the ideas (an easy to use framework to build local-first [1] apps) in my library Reactive-CRDT (https://github.com/yousefed/reactive-crdt). Feedback welcome!

All credit for the underlying tech to YJS, which has been amazing as mentioned by others in this thread.

[1]: https://www.inkandswitch.com/local-first.html