|
|
|
|
|
by rubiquity
3941 days ago
|
|
> Because gun is not a database (NoDB), it is a persisted distributed cache. The fatal flaw with databases is that they assume some centralized authority. While this may be the case initially when you are small, it always ceases to be true when you become large enough that concurrency is unavoidable. No amount of leader election and consensus algorithms can patch this without facing an unjustified amount of complexity. Gun resolves all this by biting the bullet - it solves the hard problems first, not last. It gets data synchronization and conflict resolution right from the beginning, so it never has to rely on vulnerable leader election or consensus locking. That's some of the most hand-wavy drivel I've ever read. |
|
I don't disagree with any of that, and it's not a new idea (Lotus Notes and CouchDB come to mind as databases that solve replication through conflict handling), although I'm not seeing a clear description of how this synchronization algorithm actually works. There's a description in the wiki [1], but it's unfinished. (Looking at the code, the entire project looks like quick-and-dirty, unfinished prototype, actually.)
[1] https://github.com/amark/gun/wiki/Conflict-Resolution-with-G...