This is amazing! I just spent yesterday writing a separate app engine service to use cloud datastore even though the rest of our stuff is on Firebase (RTDB wasn't a fit for us). Great to see this is out
Cloud Firestore: A New Document Database for Apps
51–60 of 174 posts
Re: Cloud Firestore: A New Document Database for Apps
#52Re: Cloud Firestore: A New Document Database for Apps
#53Earlier quoted context omitted.
Cloud Firestore has support for transactions: https://firebase.google.com/docs/firestore/manage-data/updat... So yes, if any of the operations in the transaction fails (and cannot be retried) the whole transaction will fail. It's atomic as you'd expect. If you've ever used transactions in Firebase Realtime Database you'll be happy to know that the transactions in Cloud Firestore are much easier to use since they don'…
How do you deal with consistency in the offline case? E.g. If I make a bunch of edits while disconnected, and others have made edits while connected, how are the conflicts resolved?
This works similar to the Realtime Database in that it's last-write wins (where in the offline case, "last" is the last person to come back online and send their write to the backend). This model is very easy for developers to understand and directly solves many use cases, especially since we allow very granular writes which reduces the risk of conflicts. But for more complex use cases, you can get clever and implement things like OT conflict resolution as a layer on top of last-write wins, e.g. similar to how we implemented collaborative editing with www.firepad.io on the realtime database.
PS: Hi Chris! :-)
Re: Cloud Firestore: A New Document Database for Apps
#54I’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?!
If such a project were based on top of an RDBMS, would you still expect a document/KV-oriented API, or one more SQL-ish?
Honestly I don't mind. A document API with a little manipulation on the front-end would be fine, as long as the back-end has some way of running through the relations.
A SQL-ish API might even be better, although I can see some pitfalls. Maybe base it on GraphQL as a compromise?
Either way, I'd love to have something like this.
Re: Cloud Firestore: A New Document Database for Apps
#55What's the difference with Firebase RTDB?
If you had read the post, you would know this, it even links to a more detailed post specifically about the differences towards the bottom.
Re: Cloud Firestore: A New Document Database for Apps
#56Earlier 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…
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.
Re: Cloud Firestore: A New Document Database for Apps
#57Does any of you feel cheated by Google? Rather than improving the existing product and providing backward compatibility, Google has chosen to build a new product with its own proprietary API.
I have a client who has invested significant amount time and money in Firebase Realtime Database. Now with this move, I am not sure if Google will support Firebase Realtime Database for next 5 years. So a full rewrite might be needed.
Once more it seems that going Cloud Native on one of Google's proprietary tools is very risky. I know many of the readers will say that Firebase Real-time Database is still supported. But the main question is: will it stay supported for years to come?
Google please please make an announcement and make a commitment to keep Firebase Realtime Database alive for "X" years to come. Otherwise, you are just making us developers lose faith in you.
Re: Cloud Firestore: A New Document Database for Apps
#58What's the difference with Firebase RTDB?
Here's a document they wrote comparing the two:
https://firebase.google.com/docs/firestore/rtdb-vs-firestore
Re: Cloud Firestore: A New Document Database for Apps
#59[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…
Awesome to see this. I couldn't get behind the RTDB structure, but Cloud Firestore I will definitely use!
Re: Cloud Firestore: A New Document Database for Apps
#60Earlier 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.
Or just punish big brand submissions slightly, to make it fairer for everyone else.