New Paradigm - CRDT "Revision" Tracking

If my server previously had

  • a simple Revision “clock” for each document (an integer that counts up on every change saved to the server since that instance of it started), and
  • replies to HTTPS PUT request to save document changes with the new Revision, which is used in the HTTPs callback,

how would I mock that up with Yjs?

I can deepObserve my Y.Array of Y.Map objects, make my changes in a transasaction, and respond to any change on the server by writing the new data to the server “wiki”.

I could then call myYMap.set(‘revision’,newRevision) from within the server handler. This change would then be picked up by the Client deepObserver…

but that seems fragile… and how would I use this logic within a node.js style callback-chain, where I now have to return the new revision or any error to the next callback?

Joshua Fontany

Should I just increase the revision field integer in the original transaction (the client has the last “revision” stored in a meta-data store), as some sort of Grow-Only CRDT counter? Are Yjs Maps setup for that for integers, or would I have to roll my own?

Going to read thru this to see if I can put together something for now:

Ha, turns out I didn’t need this, as the Revision field was only used during the “long poll” sync to the server, and Yjs totally side-stepped that. uring out how to link the yjs version in to the TW server’s meta-data, so we can persist a revision clock between server restarts would be worth it later.