Would I use Automerge? Hopefully this isn't TMI :)
I think it would need to clearly be worth the cost. I'm having a hard time imagining use-cases my users would have, and matter enough, that would necessitate it over the commit based backend..
I spent quite a bit of time as an FTE building out a robust-ish and efficient Yjs backend POC. This included refactoring the ProseMirror Yjs bindings into a proper TypeScript project, and specializing them for some funky use-cases. At the end of it all my personal takeaways were:
* State-based CRDT isn't great when you want a central authority in the mix anyway and are fundamentally trying to work with operations
* The exchange rate between ProseMirror's currency, steps, and some other replication strategies building blocks is too high
* ProseMirror should add the concept of range-relocation to its mappings; this is a bit of an aside but it would help retain user intent when reconciling concurrent edits involved in block relocations
As a concrete example for others imagine a knowledge base editor. You want allow certain users ONLY to comment and you want to enforce this on the backend. There are a number of ways this could be implemented but you may want the UX of optimistically allowing them to make that edit in the FE and then submit the ProseMirror steps to the backend. This will typically involve two fundamental ProseMirror steps(of which there are only a few) to set an attribute and set a mark on a node range.
You can relatively easily inspect the submitted changes to verify only the allowed operations are occurring, and authorize the user for them.
However Yjs just cares about syncing state so the documents end up equivalent, and its efficient diff format doesn't really have the info you'd need to determine what's going on. You'd need to have the actual document model loaded, and then diff the docs before/after to figure out exactly what happened. And/or patch into the Yjs binding diff algorithm which works surprisingly well but doesn't produce minimal changes and can often "over edit" the document model.
So something that was relatively simple with ProseMirror steps has become a huge thing with Yjs. And for what?
All that to say, Automerge is supposedly operation based so in theory it sounds like a better route for use cases involving a central authority(which is most if I'm speculating) and want to do extra processing on document operations.. But it'd need to bring a lot to the table to offset the time investment..
I think it would need to clearly be worth the cost. I'm having a hard time imagining use-cases my users would have, and matter enough, that would necessitate it over the commit based backend..
I spent quite a bit of time as an FTE building out a robust-ish and efficient Yjs backend POC. This included refactoring the ProseMirror Yjs bindings into a proper TypeScript project, and specializing them for some funky use-cases. At the end of it all my personal takeaways were:
* State-based CRDT isn't great when you want a central authority in the mix anyway and are fundamentally trying to work with operations
* The exchange rate between ProseMirror's currency, steps, and some other replication strategies building blocks is too high
* ProseMirror should add the concept of range-relocation to its mappings; this is a bit of an aside but it would help retain user intent when reconciling concurrent edits involved in block relocations
As a concrete example for others imagine a knowledge base editor. You want allow certain users ONLY to comment and you want to enforce this on the backend. There are a number of ways this could be implemented but you may want the UX of optimistically allowing them to make that edit in the FE and then submit the ProseMirror steps to the backend. This will typically involve two fundamental ProseMirror steps(of which there are only a few) to set an attribute and set a mark on a node range.
You can relatively easily inspect the submitted changes to verify only the allowed operations are occurring, and authorize the user for them.
However Yjs just cares about syncing state so the documents end up equivalent, and its efficient diff format doesn't really have the info you'd need to determine what's going on. You'd need to have the actual document model loaded, and then diff the docs before/after to figure out exactly what happened. And/or patch into the Yjs binding diff algorithm which works surprisingly well but doesn't produce minimal changes and can often "over edit" the document model.
So something that was relatively simple with ProseMirror steps has become a huge thing with Yjs. And for what?
All that to say, Automerge is supposedly operation based so in theory it sounds like a better route for use cases involving a central authority(which is most if I'm speculating) and want to do extra processing on document operations.. But it'd need to bring a lot to the table to offset the time investment..