Live data from Hacker News

Cloud Firestore: A New Document Database for Apps

firebase.googleblog.com

61–70 of 174 posts

Re: Cloud Firestore: A New Document Database for Apps

#61
post #2

[Firebase founder] This new database has been in the works for 2.5 years, since shortly after we joined Google. It was developed in close collaboration with the Cloud Datastore[1] team, and uses Google’s core database infrastructure. We built it because we know it can be challenging to build complex apps with our original database -- Firebase Realtime Database -- where we optimized for ease-of-use & real-time sync ov…

Regarding offline mode. How is sync done? Is this OT based? How are conflicts resolved?

Good question, and to answer this well we should probably do a blog post or something. In the meantime you could dig into the code since the clients are all open source. :-)

But basically, sync is split into two halves: writes and listens. Clients store pending writes locally until they're flushed to the backend (which could be a long time if the app is running offline). While online, listen results are streamed from the backend and persisted in a local client cache so that the results will also be visible while offline (and any pending writes are merged into this offline view). When a client comes back online, it flushes its pending writes to the backend which are executed in a last-write-wins manner (see my answer above to ibdknox for more details on this). To resume listens, the client can use a "resume token" which allows the backend to quickly get the client back up-to-date without needing to re-send already retrieved results (there are some nuances here depending on how old the resume token is, etc.).

Re: Cloud Firestore: A New Document Database for Apps

#62
post #20

Earlier quoted context omitted.

Any post having to do with YC, Google, Microsoft, Facebook, Apple, etc are voting ringed to hell by their thousands of employees. As the site has grown, HN has become a bit of a mouthpiece for large organizations through these de facto voting rings. Best idea I have is for HN to add a profile field like: "Organizations: [google]" which would prevent voting on any Google-related submissions. It could also add a discla…

It isn't even malicious - just a natural tendency people have. Like favoriting your friends picture on instagram even if it doesn't look too flattering. I love that suggestion, but how would you validate it? Registering company domains would be an exhaustive process.

Agreed that it's not malicious. But it is insidious and should be prevented. There's only a half dozen large Silicon Valley orgs worth worrying about. Maybe a dozen domains.

Re: Cloud Firestore: A New Document Database for Apps

#63
post #20

Earlier quoted context omitted.

> Why the downvote? Smells like ring voting: 4 downvotes in < 0.5 min? @dang?

Any post having to do with YC, Google, Microsoft, Facebook, Apple, etc are voting ringed to hell by their thousands of employees. As the site has grown, HN has become a bit of a mouthpiece for large organizations through these de facto voting rings. Best idea I have is for HN to add a profile field like: "Organizations: [google]" which would prevent voting on any Google-related submissions. It could also add a discla…

All of the listed corporations also have a large number of fanboys and haters, so are going to attract a large number of votes even if employees abstain.

Re: Cloud Firestore: A New Document Database for Apps

#64
post #22

I’m still looking for a product that provides firebase-levels of ease of getting up and running (no API to design, rule-based authentication, etc) , but runs on your own infrastructure, off of a traditional RDBMS. Someone tell me they’ve found the holy grail?!

horizon.io seemed to be a promising entry, but unlike RethinkDB the database, this project appears to have died with Rethink the company.

Re: Cloud Firestore: A New Document Database for Apps

#65
post #40

Sounds interesting, but is there any independent description of what it cannot do, or what would be hard to do? I just noticed it's much easier to understand a new datastore by reading its limitations (usually carefully omitted from pr articles or documentation). For example, I suspect that Firestore must be built on top of Spanner infrastructure, as it's the only way to get usable cross-datacenter many-row transacti…

We've also tried to be transparent and document our current limits here: https://firebase.google.com/docs/firestore/quotas

Re: Cloud Firestore: A New Document Database for Apps

#66

Earlier quoted context omitted.

Regarding offline mode. How is sync done? Is this OT based? How are conflicts resolved?

Good question, and to answer this well we should probably do a blog post or something. In the meantime you could dig into the code since the clients are all open source. :-) But basically, sync is split into two halves: writes and listens. Clients store pending writes locally until they're flushed to the backend (which could be a long time if the app is running offline). While online, listen results are streamed from…

Thank you!

Re: Cloud Firestore: A New Document Database for Apps

#67

A couple of questions: What's the underlying synchronisation mechanism? Is it based on CRDTs? How does this product differ from Gun.js and realm.io?

It would also be great to see a comparison to the couchDB-sync which I currently use via pouchdb/rxdb.

Re: Cloud Firestore: A New Document Database for Apps

#68
Looks great, however, I still have hopes that something similar to a GraphQL interface for a SQL based database is coming.

NoSQL is cool, but ultimately GraphQL/Apollo serves many of the same issues but has the capability of a much richer, standardized and potentially lower cost backend.

Re: Cloud Firestore: A New Document Database for Apps

#70
post #20

Earlier quoted context omitted.

> Why the downvote? Smells like ring voting: 4 downvotes in < 0.5 min? @dang?

Any post having to do with YC, Google, Microsoft, Facebook, Apple, etc are voting ringed to hell by their thousands of employees. As the site has grown, HN has become a bit of a mouthpiece for large organizations through these de facto voting rings. Best idea I have is for HN to add a profile field like: "Organizations: [google]" which would prevent voting on any Google-related submissions. It could also add a discla…

Changing or removing the downvote button would be a simpler, better fix.
Post reply on HN