CRDTs and Collaborative Playground
cerbos.dev
cerbos.dev
> If we extend it further with a fairly simple distributed mutex mechanism, we can now persist and share state across any service which can access the Redis instance!
I’m curious to hear more about the approach you took here. Does the first server to open the document hold the mutex, or do servers only hold the mutex when briefly while they persist data?
(I’ll also shamelessly plug Y-Sweet, an open source Yjs server with persistence that I contribute to https://github.com/jamsocket/y-sweet)
> or do servers only hold the mutex when briefly while they persist data?
This: it's only held during document updates, which in itself is an operation we debounce to avoid unnecessarily hammering the DB. Eventual consistency is our friend here, so this isn't a high frequency requirement (as I'm sure you're aware!).
If you can nail the "sync-on-close" mechanism in browsers, then you're golden :-)
How do you handle it within y-sweet (cool project, BTW!)?
We run Y-Sweet in Plane.dev (also our open source project). Plane runs a process for every document across a pool of compute, so each process effectively has a lock on that document’s data and can persist on a loop without worrying about conflicting with another writer.
If anyone want to go down that rabbit hole: https://www.exhypothesi.com/clocks-and-causality/
I'll also commend the author's attempt at DIY! Even if your case does not require a custom solution, it's healthy to understand how your tools work.
[0] https://loro.dev
Even on the edge cases, most of it just relates to what primitives are exposed in the API, and we've found the library's author to be highly engaged in creating solutions.
We've found it to be an incredibly well designed library.