I think the impressive part here isn't Linear's sync engine, but the fact that Evan Hu went through painstakingly reverse-engineer the engine by inspecting traffic and obfuscated code and was able to write documentation that is correct and more complete than what Linear publishes internally.
I have a first attempt at a sync engine for my app, but it's very primitive. Just a websocket that sends updates based on database triggers. If you miss one, you have to do a full reload. I know I'll need something better in a year or so.
Any advice on what route to take with creating a sync engine for a product like mine? Self-hosted, single binary web app (Rust) + Postgres db. Frontend is based on VueJS. I've looked at the readme of Yjs and was considering that. I'm a solo dev for now.
I'm tempted to feed Cursor this description of the reverse engineered solution of Linear, but I doubt it'll be successful.
I'm using Loro as the CRDT as well as Iroh for byte transfer, works well. You can look at ElectricSQL as a Postgres sync engine but it won't do conflict resolution for you and it's hard doing CRDT operations on relational databases on general.
Same author, not necessarily sure why it's on two different domains with different content but they open sourced their sync engine. If you're interested in this topic, I'd follow. Their newsletter as they have great stuff.
Yjs isn't a sync engine, it's a data structure for managing distributed concurrent updates and ensuring they are conflict free.
Whether you use it feels orthogonal to the problem you're describing.
---
For a minimal scope solution, have you considered making a table in your database where you log each update? Then you can keep an id of your most recent update locally and on websocket reconnection ask for the updates after your current change.
Thanks, that helps! Like I said I had only very briefly looked at Yjs.
The thought of an "updates" table has crossed my mind yes, but after some time you want a "materialized view" instead of replaying the history from the start, and that's where it gets complicated ;)
I'll take a look at those alternatives. I'd rather have something stable than having to re-invent the wheel. Thanks again!
Linear’s sync engine maintains a local, in-memory object graph (backed by MobX) and persists all changes to IndexedDB, allowing immediate, offline-first updates.
There is a proliferation of sync tools and little standardization. Here some in local-first space [0]. Martin Kleppmann in his talk last year spoke [1] the need for a generic sync protocol, which was very interesting.
Most certainly, if the data that the mobile app consumes is bounded and the same data is accessed frequently. Uber for example could have benefited from a sync architecture immensely (I tried to implement one back in the day, but was too late to the party as hypergrowth blocked any attempts at switching architectures). Sync
architectures are not only great from a user experience point of view, but also for developer productivity and velocity. Sync takes care of a slew of problems that makes feature development slow. I gave a talk on this at last year's Local First conf https://www.youtube.com/watch?v=VLgmjzERT08&t=4s.
Ecosystem for local-first and mobile is pretty immature, at least for Swift.
In comparison to the web where there's so many libraries e.g. Zero, LiveStore, LiveBlocks, I've yet to find a good GRDB (sqlite abstraction) integration / client.
Offline-first is definitely very strong, but now how do I get data into a remote database with conflict resolution support?
You could achieve something almost identical with Replicache + (Mobx or Orama). Only mentioning Mobx because it's what Linear uses. That level of the implementation is interchangeable.
If you're using AI to write all those em-dashes, please add a disclaimer.
For humans i would say a shorter summary is Linear.app syncs a client IndexedDB with the server using naive last-write-wins, no conflict detection, no OT, no CRDT. There's a global sync ID that the server is in control of. Most of the article describes minutae of the json schema.
I’ve built a custom layout for that (and a bunch of other symbols I frequently use). ⌥ hyphen for en-dash, ⌥ ⇧ hyphen for em-dash (and ⌥ M is for minus): https://typo.ale.sh/
(The idea isn’t new, of course: the default macOS layout’s 3rd layer is absolutely bonkers. I think Ilya Birman was the first: https://ilyabirman.net/typography-layout/)
I am anti-reading content generated by probabilistic model of human language, especially if published without much editing. Em-dash is a strong indicator of such.
Readit News
Any advice on what route to take with creating a sync engine for a product like mine? Self-hosted, single binary web app (Rust) + Postgres db. Frontend is based on VueJS. I've looked at the readme of Yjs and was considering that. I'm a solo dev for now.
I'm tempted to feed Cursor this description of the reverse engineered solution of Linear, but I doubt it'll be successful.
Look into these as well:
https://www.typeonce.dev/article/how-to-implement-a-sync-eng...
https://www.sandromaglione.com/newsletter/lessons-from-imple...
Same author, not necessarily sure why it's on two different domains with different content but they open sourced their sync engine. If you're interested in this topic, I'd follow. Their newsletter as they have great stuff.
Whether you use it feels orthogonal to the problem you're describing.
---
For a minimal scope solution, have you considered making a table in your database where you log each update? Then you can keep an id of your most recent update locally and on websocket reconnection ask for the updates after your current change.
Similar to how in-app notifications work.
---
For local-first, you can use things like:
https://tinybase.org/https://electric-sql.com/https://livestore.dev/
But they are pretty foundational. You use them as your storage layer in the front end. So worth considering the scope of the change.
The thought of an "updates" table has crossed my mind yes, but after some time you want a "materialized view" instead of replaying the history from the start, and that's where it gets complicated ;)
I'll take a look at those alternatives. I'd rather have something stable than having to re-invent the wheel. Thanks again!
We build same experience at www.teamcamp.app
[0] https://localfirstweb.dev/
[1] https://www.youtube.com/watch?v=NMq0vncHJvU&t=1016s
https://www.localfirst.fm/landscape
LiveStore shows recreating linear as one of their examples though I haven’t tried it. It was on the front page recently https://news.ycombinator.com/item?id=44105412
Deleted Comment
In comparison to the web where there's so many libraries e.g. Zero, LiveStore, LiveBlocks, I've yet to find a good GRDB (sqlite abstraction) integration / client.
Offline-first is definitely very strong, but now how do I get data into a remote database with conflict resolution support?
Dead Comment
Deleted Comment
For humans i would say a shorter summary is Linear.app syncs a client IndexedDB with the server using naive last-write-wins, no conflict detection, no OT, no CRDT. There's a global sync ID that the server is in control of. Most of the article describes minutae of the json schema.
(The idea isn’t new, of course: the default macOS layout’s 3rd layer is absolutely bonkers. I think Ilya Birman was the first: https://ilyabirman.net/typography-layout/)