This is a really great article and overview. It is a tad light on the most important subjects of CRDTs (Conflict free Replicated Data Types).
After having worked on these types of problems for a decade, and successfully running an Open Source database startup for nearly a half decade, they are certainly and only the right way to go.
They seem to suggest they aren't well adopted, and suggest there are severe limitations that are withholding their adoption.
This was true with append-only or log-based CRDTs.
But now, state-based graph CRDTs (like we've implemented in https://github.com/amark/gun ) have solved that. The only thing you can't do with them is Global Strong Consistency (think banking), but their Strong Eventual Consistency guarantees make them the best solution for literally everything else.
They are also run in production at large large sites, like the Internet Archive (top 300 site globally), D.Tube (1M monthly uniques), notabug.io (P2P reddit), etc. with GUN.
The article kind of makes this joke:
> (otherwise our lives would be too easy, right?)
But here is the kicker, both Internet Archive and NAB integrated/built in 1 week. Literally yes it makes people's lives easier.
And you should too! Next time you build a non-banking app, you should consider using state-based graph CRDT to cover 99.99% of your use cases!
You are getting downvoted because of your attitude. Even if your GUN database is really that awesome, here are some points for you to reflect on:
- What is "easy" for you might not be for others.
- Banking systems don't use strong consistency. They can just rollback/swallow the costs of invalid transactions after the fact. Online mom-and-pop shop... maybe they can, maybe its better for the site to just have some downtime sporadically and avoid such hassles entirely.
- P2P is a nightmare for anything that requires audit trails (and there are legal requirements about that in many industries).
- There exists a whole ecosystem of databases dedicated to analytical processing workloads (OLAP). Graph databases are typically not the best at it.
- Conflicts happen. Your "conflict-free" datatypes embed the conflict resolution rules in the data structure. This is fine for some conflict resolution rulesets, but it cannot be done for some other sets (e.g.: in these weird circumstances, the user decides what the resolution is by clicking a button).
After having worked on these types of problems for a decade, and successfully running an Open Source database startup for nearly a half decade, they are certainly and only the right way to go.
They seem to suggest they aren't well adopted, and suggest there are severe limitations that are withholding their adoption.
This was true with append-only or log-based CRDTs.
But now, state-based graph CRDTs (like we've implemented in https://github.com/amark/gun ) have solved that. The only thing you can't do with them is Global Strong Consistency (think banking), but their Strong Eventual Consistency guarantees make them the best solution for literally everything else.
They are also run in production at large large sites, like the Internet Archive (top 300 site globally), D.Tube (1M monthly uniques), notabug.io (P2P reddit), etc. with GUN.
The article kind of makes this joke:
> (otherwise our lives would be too easy, right?)
But here is the kicker, both Internet Archive and NAB integrated/built in 1 week. Literally yes it makes people's lives easier.
And you should too! Next time you build a non-banking app, you should consider using state-based graph CRDT to cover 99.99% of your use cases!