Amazing stuff! 🚀

[charlie-maloney]

Hey @wzhudev -- This is some incredible, diligent work! Thanks for sharing this with the world. I can't imagine how long this took you.

I have read through it twice now, and still probably need a few more passes to fully grok it.

A couple questions popped up as I was reading through it:

---

issue.title = "New Title";
issue.save();

If calling save() generates a transaction for that model, are you aware of how cross model transactions occur?

These models possess properties and references to other models, many of which are observable (via MobX) to automatically update views when changes occur. 

Are you aware of how the UI actually queries the models? For example, is a controller or something similar exposed to the UI? Or do they just query the Object Pool directly?

Note that the id of the third sync action is 28 greater than the id of the second sync action, indicating that the lastSyncId is tied to the entire database, not just the workspace...If the client's lastSyncId is smaller than the server's, it indicates that the client is out of sync and has not received some delta packets

If this is the case, wouldn't the last sync id for a client workspace almost always be less than the DB wide sync id? For example, if no changes happened in your workspace, but some changes happened in a totally unrelated org/workspace, your client would think you are out of sync since the global lastSyncId has been incremented, yet there are no new delta packets for you to handle...?

Also, to clarify, is backendDatabaseVersion just the schema version of the database? (e.g. gets incremented after every migration?).

Other Questions:

• As far as security goes, if a user is kicked from a team, doesn't that mean that all of their data is still persisted in IndexedDB?
• I see you are working on another project called Univer (which I also got curious about 😄 ) -- are you planning to try to implement a similar sync like engine in that project?
• What are your thoughts on replicache and zero (i.e. generalized sync engines)?

[wzhudev]

Great questions, @charlie-maloney!

Cross-model transactions

I tried updating the same property (e.g., priority) on multiple issues. Linear creates a separate UpdateTransaction for each one. It seems there’s no cross-model transaction support — each transaction targets a single object. That’s ideal — if one issue is deleted mid-update, it's better to drop that update than the whole batch.

How the UI queries models

The SyncedStore class exposes many access methods. If you check Root.js, you’ll find frequent use of findById, allModelsOfType, and similar helpers.

lastSyncId

Yes, the client’s lastSyncId is typically behind the backend’s. But that’s fine — on the next bootstrap, the client sends its lastSyncId (performing a partial bootstrap), and the backend determines what delta packets are missing.

backendDatabaseVersion

Not sure exactly when Linear updates this — it’s backend-controlled — but doing so on schema changes makes perfect sense.

When a user is removed from a sync group

Apologies if the doc wasn’t clear: when a client receives a "leave group" sync action, it deletes all related models in that group. Please check the removeSyncGroups method.

Univer

Univer currently uses OT. Switching to object-based sync doesn’t seem viable due to the complexity of preserving user intent.

Thoughts on Replicache and Zero

I haven’t explored them in depth yet, but they look promising. I’ll share thoughts once I dig in.

[charlie-maloney]

Thanks for the detailed reply, @wzhudev! — this is super helpful. I’m building a financial modeling software, and between seeing how you’ve implemented certain features in the Univer codebase and this write-up, it’s all been incredibly insightful. The plugin-based architecture of Univer is especially interesting.

[wzhudev]

Thanks for the detailed reply, @wzhudev! — this is super helpful. I’m building a financial modeling software, and between seeing how you’ve implemented certain features in the Univer codebase and this write-up, it’s all been incredibly insightful. The plugin-based architecture of Univer is especially interesting.

So glad they are helpful to you. If would like to know more about Univer's architecture, you may find our documentation helpful as well.

[charlie-maloney]

Thanks! I've been reading the docs as I've been looking through the codebase -- very helpful.