Note that a client that makes offline changes before the snapshot is generated, and then reconnects after it is generated and the past updates have been removed, will not be able to merge conflicts. For true offline-first functionality you need the whole history.
It’s usually best to store the YJS updates as-is. They are heavily optimized and allow efficient storage, syncing, and transmission over the wire. But I understand that a lot of projects have different needs, and people often prefer JSON or snapshots. I’m just not sure of the full implications for the conflict-resolution behavior.
Thanks raine! The issue on my side is that sending a bunch of updates to the clients from the server is way slower than sending a big one.
Now I have noticed that the document state is growing fast, even though the content is empty. The server doesn’t need to store every transaction, only the content of the document when the snapshot was taken and any updates that have been made since then. Do you know how would be possible to do that?
I’m not sure I know what you mean here. y-websocket sends all updates in a single response to the client in sync step 2. If you are using a different WebSocket server, you would need to emulate that behavior.
The process is described here:
Are you sure? CRDT’s rely on the full document history to recreate the document state and resolve conflicts. In a distributed environment, there is no way to guarantee that all clients are up-to-date with a given snapshot.
Maybe there are others who have gotten snapshots to work in this fashion though.
Unfortunately, I can’t use y-websocket and I can’t modify the existing WebSocket server, but so far my approach seems to work. And I have just found the solution to the growing document state, which was worrying me.
The solution consists in using Y.snapshot to get the document state at a given point -when I want so save the snap- without all the document history.