Really interesting...you can build a similar (websocket/db backed) app with LiveView out of the box, no? Any idea how well that'd hold up against this solution?
A simple way to build collaborative web apps
11–20 of 73 posts
Re: A simple way to build collaborative web apps
#12I haven't yet done this but based on some research it seems to me like the core of any collaborative app today (that wants to avoid Firebase and the other hosted platforms like Replicache seems to be) is easiest served by picking some CRDT library.
There are a couple of open-source CRDT libraries that provide both clients and servers (yjs [0] and automerge [1] are two big ones for JavaScript I'm aware of).
My basic assumption is that as long as you put all your relevant data into one of these data structures and have the CRDT library hook into a server for storing the data, you're basically done.
This may be a simplistic view of the problem though. For example I've heard people mention that CRDTs can be space inefficient so you may want/have to do periodic compaction.
Re: A simple way to build collaborative web apps
#13So far I've managed to keep the state in my side-project in sync with Websockets and Redux, Replicache sounds like the kind of solution I'd love to use, but boy the pricing makes it impossible to even consider.
I don't have any plans to use Replicache, but I went and looked at the pricing and I was kind of struck by your comment. Looking at it, it seems pretty fair to me? Especially under 10k MAC's. It seems like a flat rate / month is pretty nice too. Plus, it's free for all non-commercial use.
Am I wildly off base here? Is it just that middle tier jump to over 10k that is a no go?
Again, I don't have a horse in this race or even my own startup, just trying to understand if my own judgement is way off.
Re: A simple way to build collaborative web apps
#14I'm really glad to see an article like this. I've worked in the space for a while (Fluid Framework) and there's a growing number of libraries addressing realtime collab. One of the key things that many folks miss is that building a collaborative app with real time coauthoring is tricky. Setting up a websocket and hoping for the best won't work.
The libraries are also not functionally equivalent. Some use OT, some use CRDTs, some persist state, some are basically websocket wrappers, fairly different perf guarantees in both memory & latency etc. The very different capabilities make it complicated to evaluate all the tools at once.
Obviously I'm partial the Fluid Framework, but not many realtime coauthoring libraries have made it as easy to get started as Replicache. Kudos to them!
A few solutions with notes...
- Fluid Framework - My old work... service announced at Microsoft Build '21 and will be available on Azure
- yJS - CRDTs. Great integration with many open source projects (no service)
- Automerge - CRDTs. Started by Martin Kleppman, used by many at Ink & Switch (no service)
- Replicache - Seen here, founder has done a great job with previous dev tools (service integration)
- Codox.io - Written by Chengzheng Sun, who is super impressive and wrote one of my fav CRDT/OT papers
- Chronofold - CRDTs. Oriented towards versioned text. I'm mostly unfamiliar
- Convergence.io - Looks good, but I haven't dug in
- Liveblocks.io - Seems to focus on live interactions without storing state
- derbyjs - Somewhat defunct. Cool, early effort.
- ShareJS/ShareDB - Somewhat defunct, but the code and thinking is very readable/understandable and there are good OSS integrations
- Firebase - Not the typical model people think of for RTC, but frequently used nonetheless
Re: A simple way to build collaborative web apps
#15So far I've managed to keep the state in my side-project in sync with Websockets and Redux, Replicache sounds like the kind of solution I'd love to use, but boy the pricing makes it impossible to even consider.
I don't have any plans to use Replicache, but I went and looked at the pricing and I was kind of struck by your comment. Looking at it, it seems pretty fair to me? Especially under 10k MAC's. It seems like a flat rate / month is pretty nice too. Plus, it's free for all non-commercial use. Am I wildly off base here? Is it just that middle tier jump to over 10k that is a no go? Again, I don't have a horse in this race…
I would quickly be in the $500/mo tier and that would be a consequent cost to handle since I don't really make that kind of profit yet. But I have to agree anything beyond 10K is very reasonable given the features.
I just kind of wish they had an more affordable bracket between 500 and 10K but they probably have reasons not to.
Re: A simple way to build collaborative web apps
#16Really interesting...you can build a similar (websocket/db backed) app with LiveView out of the box, no? Any idea how well that'd hold up against this solution?
This was my first thought as well.
Re: A simple way to build collaborative web apps
#17What about conflict resolution? If two users update the same record/field around the same time? Isn’t that the trickiest part of real time?
That's what Replicache[0] solves, it provides for Causal+ Consistency across the entire system. "This means that transactions are guaranteed to be applied atomically, in the same order, across all clients. Further, all clients will see an order of transactions that is compatible with causal history. Basically: all clients will end up seeing the same thing, and you're not going to have any weirdly reordered or dropped…
It appears Replicache doesn't use CRDTs since it has a central source of truth: https://news.ycombinator.com/item?id=22175530
See also the commentary here: https://doc.replicache.dev/guide/local-mutations
This sounds a lot like Operational Transform but without the transform part - it assumes that locally applied mutations can be undone and rebased without user interaction. But I feel like the Google Wave team would have a lot of objections to the idea that this can just be ignored. If your state is just a group of key value stores where last write wins and everyone can agree on who's last, that's fine, but text/token streams require a notion of transformation that I'm worried Replicache simply glosses over.
Re: A simple way to build collaborative web apps
#18I'm interested how this stacks against Phoenix Channels + Presence.
Re: A simple way to build collaborative web apps
#19I haven't yet done this but based on some research it seems to me like the core of any collaborative app today (that wants to avoid Firebase and the other hosted platforms like Replicache seems to be) is easiest served by picking some CRDT library. There are a couple of open-source CRDT libraries that provide both clients and servers (yjs [0] and automerge [1] are two big ones for JavaScript I'm aware of). My basic a…
Would Chronofold works for this too?
Re: A simple way to build collaborative web apps
#20I haven't yet done this but based on some research it seems to me like the core of any collaborative app today (that wants to avoid Firebase and the other hosted platforms like Replicache seems to be) is easiest served by picking some CRDT library. There are a couple of open-source CRDT libraries that provide both clients and servers (yjs [0] and automerge [1] are two big ones for JavaScript I'm aware of). My basic a…
Would Chronofold works for this too?
If this [0] is what you're talking about, at the moment yjs and automerge are significantly more full-featured and used by many major companies.