distributed-counters
shelf
| distributed-counters | shelf | |
|---|---|---|
| 1 | 2 | |
| 6 | 52 | |
| - | - | |
| 10.0 | 0.0 | |
| almost 11 years ago | over 1 year ago | |
| Erlang | JavaScript | |
| - | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
distributed-counters
-
Downsides of Offline First
I was also a "true believer" in CRDTs for a long time, implementing my first ones in Erlang about 9 years ago[1], but my opinion of where they fit has changed significantly.
The one issue with CRDT that I find is rarely mentioned and often ignored is the case where you've deployed these data structures that include merge logic to a set of participating nodes that you can't necessarily update at will. Think phones that people don't update, or IOT/sensor devices like electric meters or other devices "in the wild".
When you include merge logic – really any code or rules that dictate what happens when the the data of 2 or more CRDTs are merged – and you have bugs in this code running on devices you can never update, this can be a huge mess. Sure you can implement simple counters easily (like the ones I linked to), and you can even use model checking to validate them. But what about complex tree logic like for edits made to a document? Conflict resolution logic? Distributed file system operations? These are already very complex and hard to get right without multiple versions involved and unfixable bugs causing mayhem.
Having to deal with these bugs in the context of a fleet of participants on a wide range of versions of the code, the combinatorial explosion of the number of possible interactions and effects of these differing versions and bugs taken together can really become impossible to manage.
I'd be interested to hear from folks who have experience with these kinds of issues and how they have dealt with them, especially if they are still convinced that CRDTs were the right choice.
[1] https://github.com/nicolasff/distributed-counters
shelf
-
Show HN: Bike – macOS Native Outliner
I think you could encode a “shelf” last-write-wins CRDT into your HTML using data attributes without exploding your file size. You would need to add a data-version attribute, and if you want to support hand-editing or editing by programs that don’t understand the CRDT, a CRC32 or other parity as data-parity so your loader can tell when a user might have edited a row without updating data-version.
Shelf is really simple - the JS implementation is tiny (https://github.com/dglittle/shelf) and a walkthrough of the algorithm here: https://bartoszsypytkowski.com/shelf-crdt/amp/
It wouldn’t handle character level sync - but would let you merge documents at a rows/items/blocks level.
-
Downsides of Offline First
The CRDT I was referencing was Shelf by Greg Little. He's given a few talks about it at the braid meetups. When he first showed it off, Kevin Jahns (the Yjs author) was also there and was as impressed as I was:
https://braid.org/meeting-8
The code is all here. Its tiny:
https://github.com/dglittle/shelf
What are some alternatives?
offix - GraphQL Offline Client and Server
swift-collections - Commonly used data structures for Swift
absurd-sql - sqlite3 in ur indexeddb (hopefully a better backend soon)
crdt-example-app - A full implementation of CRDTs using hybrid logical clocks and a demo app that uses it
Homebrew-cask - 🍻 A CLI workflow for the administration of macOS applications distributed as binaries