Gun – “Self-hosted Firebase” (opens in new tab)

I don't see what's hand-wavy about it. He makes a clear and succinct point: In a distributed database, managing consistency at scale gets complex because most systems are designed to assume a centralized authority [of consistency]. By removing the centralized authority and making conflict resolution the main mode of operation, the design can (according to the author) be made simpler.

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...

I'd love to see Kyle Kingsbury put that through it's paces.

You are right, it is very similar to Couch/PouchDB. Honestly, I tried Couch back in 2010 and wasn't very impressed and haven't really kept up with it since. Although I regularly hear good things about it and am aware it is one of the rare ones that is offline first. MongoDB wound up winning that market, so I didn't really think to provide a comparison to Couch.

So pardon my out-of-date ignorance:

1. Depends upon what you want. GUN can do dynamic queries and has realtime push notifications baked right in. What you didn't ask is how GUN is worse. Well, CouchDB is stable and has security - stuff which we're still working on.

2. GUN is a graph database which allows you to have key-value, relational, and document based data. Couch is a document based database. GUN gets embedded into your application server, while CouchDB has to run its own database server which then requires maintenance.

3. Mathematically speaking, any matrix (table) or tree (document) can be represented in a graph. But not all graphs can be represented as a matrix or tree. So building GUN ontop of CouchDB would have come with a lot of overhead, especially since CouchDB does not have dynamic queries.

Hope this helps! Let me know if you have any other questions.

Good point, haven't heard that one before. Let me clarify. GUN requires no additional maintenance because it gets embedded into your app, compared to most databases which require you to run (and maintain) a database server.

If you do not want to even run your own app servers, I'm more then happy to let you use my free GUN backend so that way you do not even have to worry about that.

Consensus? Absolutely not. I definitely need to add more documentation and resources on this - in fact I'm doing a talk on how my conflict resolution algorithm works out in Berlin in a few weeks. Check the conference out at: https://2015.distributed-matters.org/ber/ . After that I should have much better materials on this available for people.

Briefly and naively, the way it works is a Vector Clock + Timestamp combo. Timestamps have bad exploits, and Vector Clocks don't work well in ephemeral environments. If you combine the two together they compensate for the vulnerabilities of the other. Every peer acts as a state machine operating inside of an open-closed boundary function (nothing fancy here, this is the same stuff you learned in middle/highschool). This does NOT give you Global Consistency, as different peers might have slightly different boundaries because of clock drift (you can use a separate service to minimize this), but they will all become Eventually Consistent.

This helpful? Any other questions?

Yes, I am skeptical about automatic conflict resolution too. But the project is interesting and uses many right concepts.

I believe deepstream which received good feedback on HN also solves a similar problem.

With such proliferation of self hosted FireBase, can anyone in the know share their experiences with these solutions?

With a two way dotted arrow, obviously.