Really cool. I'm working on .Net project that I've also adopted a "single dependency" stance on; that being Postgres. I'm pretty thrilled to see I'm not the only one lol!
I plan to use Orleans to handle a lot of the heavy HA/scale lifting. It can likely stand in for Redis in a lot of cache use cases(in some non-obvious ways), and am anticipating writing a Postgres stream provider for it when the time comes.. Will likely end up writing a Postres job queue as well so will definitely check out River for inspiration.
A lot of postgres drivers, including the .Net defacto Npgsql, support logical decode these days which unlocks a ton of exciting use cases and patterns via log processing.
I worked at Rundeck on the core engineering team through the PagerDuty acquisition. Left my job start of the year to bootstrap a reboot, StepWise, that embraces and leans into that iterative approach to automation.
We are looking for early adopters to try it out and give feedback soon here. Would love to get your thoughts; https://stepwisehq.com .
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..
Currently using TipTap as a higher level abstraction on top of ProseMirror. Mostly for the React node view support which works very well. I try to implement most other stuff as straight ProseMirror plugins.
Shameless plug for some ProseMirror FOSS ecosystem contributions I've recently made:
A commit-based collab plugin that's far more performant under heavily active client loads than stock. I'm a fan of YJS, but not a fan of state-based CRDT layer on top of ProseMirror for my use cases. Wrote about this here: https://stepwisehq.com/blog/2023-07-25-prosemirror-collab-pe... .
I also translated the core ProseMirror projects of model, transform, and test-builder to C# so you can build robust backends in a C# monolith. All tests on those projects have been translated as well. Wrote about this here: https://stepwisehq.com/blog/2023-07-17-announcing-prosemirro... .
Hope to release more FOSS projects along the way; lot of taking from ProseMirror compared to what's given back IMHO(not targeted at TipTap which provides a lot of value). I've got some stuff geared towards minimizing keystroke-to-paint latency which I hope to write about soon. Ideally we will reach a point where we contribute funds to the ProseMirror project.
I plan to use Orleans to handle a lot of the heavy HA/scale lifting. It can likely stand in for Redis in a lot of cache use cases(in some non-obvious ways), and am anticipating writing a Postgres stream provider for it when the time comes.. Will likely end up writing a Postres job queue as well so will definitely check out River for inspiration.
A lot of postgres drivers, including the .Net defacto Npgsql, support logical decode these days which unlocks a ton of exciting use cases and patterns via log processing.