Yet another useless nosql snake oil.
Cloud Firestore: A New Document Database for Apps
91–100 of 174 posts
Re: Cloud Firestore: A New Document Database for Apps
#92[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…
Do you see this as an equivalent to Dynamodb ? Very timely ;)
DynamoDB does not come with offline sync.
Re: Cloud Firestore: A New Document Database for Apps
#93[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…
Can you provide anything to reassure potential users that this will still exist in five or ten years time?
The Firebase Realtime Database has been around for ~5 years (and is still fully supported after this launch).
Cloud Datastore has been around in some form (started as App Engine Datastore) since 2008.
Cloud Firestore was a massive multi-year joint effort between Firebase and Google Cloud. Google is investing heavily in both, and this is a big deal for our teams.
Re: Cloud Firestore: A New Document Database for Apps
#94We're one of the startups shown in the announcement (Crypto Portfolio Tracker [1] - bottom right logo). Firestore enabled us to build the first version of our app in under a week. We've been using the product for over two months now, and it's given us a competitive edge in being able to develop features rapidly and not having to spend time on operations.
One of the things we liked about Firestore is that it takes the best practices of Realtime Database and makes them more explicit. Before, your RD database structure would look like `collection/{id}` and `collection_sub_collection/{id}/{sub_id}` in order to avoid loading sub-collections in top-level queries. With Firestore, this collections pattern is now part of the API itself, and sub-collections aren't fetched when the parent is fetched.
Another feature we liked is that transactions are no longer limited to a subtree of your database. Before, you would have to structure all of your transactional data under a single path. This would sometimes lead to having to pile-in unrelated data into a single object, such as adding payment data under a users object instead of a separate collection, so that you could atomically modify both user and payment data. With Firestore, transactions are global, so this isn't a concern anymore - we are free to structure our data in any way that makes sense for our app.
Overall, we had a great experience with Firestore during the alpha, and we'll definitely be keeping it as part of our technology stack. Congrats on the launch!
(disclaimer: this post isn't sponsored by Firebase)
Re: Cloud Firestore: A New Document Database for Apps
#95Does 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 n…
[Firebase founder] To offer better querying, improve the data model, and increase scalability we had to build an entirely new database. The original technical choices we made as a startup weren't able to support the featureset Cloud Firestore has. Even if we tried to improve upon the existing Realtime Database product, we would have had to make breaking changes that would have required you to rewrite your code (and likely shipped a worse product).
Regarding deprecation: you can be comfortable continuing to build on the Realtime Database. We don't intend to deprecate either database, since both are useful in different situations, depending on what you're building. We recommend using the Realtime Database for a number of usecases[1]
We're not posting a "Realtime Database will be supported for X years" statement because many may interpret this as "the Realtime Database is deprecating in X years", which isn't the case.
[1] https://firebase.googleblog.com/2017/10/cloud-firestore-for-...
Re: Cloud Firestore: A New Document Database for Apps
#96I’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?!
We're a popular alternative, https://github.com/amark/gun
Some cool differences:
- MIT/ZLIB/Apache2 licensed.
- Graph data structures (document, key value, tables, relations, and more!)
- Decentralized like IPFS!
- Alpha prototype for end-to-end encryption and user authentication / permissions security.
And a bunch more :).
Re: Cloud Firestore: A New Document Database for Apps
#97Earlier quoted context omitted.
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 impleme…
Hey Michael! Congrats on the launch :) Providing a one-size-fits-all solution here is probably impossible, but it seems like it would be nice to provide some mechanism to be notified that you're making edits based on stale information. If such a mechanism existed, it would be easy to add a bunch of canned merge strategies. In doing so you can probably teach people a little bit about the pitfalls they're likely to run…
[deleted]
Re: Cloud Firestore: A New Document Database for Apps
#98Earlier quoted context omitted.
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 impleme…
Hey Michael! Congrats on the launch :) Providing a one-size-fits-all solution here is probably impossible, but it seems like it would be nice to provide some mechanism to be notified that you're making edits based on stale information. If such a mechanism existed, it would be easy to add a bunch of canned merge strategies. In doing so you can probably teach people a little bit about the pitfalls they're likely to run…
It looks to me like Firestore's API doesn't include a "default" way to upload user edits to documents. Conflict detection is possible using the transactions - https://cloud.google.com/firestore/docs/manage-data/update-d... - you can do something like HTTP's PUT If-Unmodified-Since (or PUT If-Match).
Re: Cloud Firestore: A New Document Database for Apps
#99Should I really be so excited for built-in query support in 2017? For a mature product supported by a dominant tech company? Because I am.
Re: Cloud Firestore: A New Document Database for Apps
#100I’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?!
Deepstream.io is a cloud platform and opensource real-time server that provides rule based permissions, authentication and a real-time data store that can be plugged into different any database (we use Postgres under the hood for the cloud).
It provides the same name document/collection concepts, but search abilities are still under development.
Side note, Im one of the cofounders :D
Generally this move by Firebase makes a lot of sense! Building large real-time apps usually requires smaller documents or else things get super odd at scale.