Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Firestore: A New Document Database for Apps

firebase.googleblog.com

Post reply on HN
Print view View original

111–120 of 174 posts

Re: Cloud Firestore: A New Document Database for Apps

#111

Post by vim_wannabe »

insomniacity wrote: post #77
jamest wrote: 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…

How goes the work to improve customer service and support? Thinking about https://news.ycombinator.com/item?id=14359801 , what improvements have you made in the last 139 days that would make us want to build on this?

How does customer service work with technical services?

There is very little time for developers of a system to use on support, so how do you go about building the baby padding around them? I would imagine at least 97.5% of support requests are a problem on customers end, so just how much support staff would you need for a global service like this?

Re: Cloud Firestore: A New Document Database for Apps

#112

Post by jrowley »

stefano wrote: post #75

I don't like this trend of creating new closed source database systems that only exist on a single cloud provider. Your data is your most valuable asset, and by using this you're locking it inside Google servers. If they decide five years from now to discontinue it, or to raise the pricing 10x, you're screwed. Are most developers only working on short term projects? Why would you put yourself in such a situation inst…

How many of projects last 5 years? I'm notorious for short term thinking, but often times if pays off.

Re: Cloud Firestore: A New Document Database for Apps

#113

Post by fictionfuture »

ruslan_talpa wrote: post #72
fictionfuture wrote: post #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.

It's coming https://subzero.cloud/ :)

looks cool, interested to see the backend you're using and if it requires lockin.

did Kreatank do that logo?

Re: Cloud Firestore: A New Document Database for Apps

#114

Post by victorhooi »

insomniacity wrote: post #77
jamest wrote: 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…

How goes the work to improve customer service and support? Thinking about https://news.ycombinator.com/item?id=14359801 , what improvements have you made in the last 139 days that would make us want to build on this?

So my reading here is that the main issue is Firebase was undercharging customers, due to a bug.

They didn't go back retroactively and ask for back payments, but just started charging them accurately going forward.

Of course, that bill caused shock for some people, as they suddenly realised, "Oh s*it, I'm being charged accurately now, my bills are huge!!!"

In this customer's case, apparently they were also doing something bad with TLS tickets and not setting keep-alives - basically causing them to spam Firebase with connections:

https://news.ycombinator.com/item?id=14357270

Of course, there's the other issue of a communication breakdown which they said they're working on.

Re: Cloud Firestore: A New Document Database for Apps

#115

Post by anderspitman »

stefano wrote: post #87
cobookman wrote: post #82

Earlier quoted context omitted.

> Your data is your most valuable asset, and by using this you're locking it inside Google servers. If they decide five years from now to discontinue it, or to raise the pricing 10x, you're screwed. You'd be able to move your data off of firestore. And there's legal business contracts around pricing. Google can't just raise pricing 10x overnight.

Sure, you can move it, but how much code will you need to rewrite? How much effort to convert the data to a new database format? And how much more development time to migrate your data without taking your service down during the migration? It's a very expensive move that I don't think people consider when choosing this kind of solution.

Have you used Firebase before? In my (rather limited) experience, the development speed increases from not needing to manage your own Mongo store, not to mention implementing all of their real-time features on top of that, are quite valuable. At least for an MVP I wouldn't hesitate to do the first version with Firebase to test my assumption even if I knew I wasn't going to use it at scale. Plus you can always wrap Firebase in your own layer from the beginning.

Re: Cloud Firestore: A New Document Database for Apps

#117

Post by mikelehen »

lozenge wrote: post #98
ibdknox wrote: post #71

Earlier quoted context omitted.

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

Good point. read-modify-write transactions are a good way to detect conflicts and get a chance to handle them, but they're unfortunately limited to while the client is online. If the client is offline, the transaction will fail so they're not useful for general conflict resolution. This was an intentional decision because there's not a straightforward way to preserve the intent of the transaction across app restarts. But there may be options for adding some sort of conflict resolution strategy in the future that leverages the same underlying primitives that transactions use today.

Re: Cloud Firestore: A New Document Database for Apps

#118

Post by mikelehen »

ibdknox wrote: post #71
mikelehen wrote: post #53

Earlier 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…

Thanks for the feedback. I think you're right and we're interested in exploring what we can do to help people more in the future. One of the really nice things about Cloud Firestore is that documents are versioned with timestamps in such a way that we could definitely detect and expose conflicts and let you decide how to deal with them... It's mostly a matter of identifying the common use cases and then figuring out the right API to make them possible without going too far into the deep end of conflict resolution.

Re: Cloud Firestore: A New Document Database for Apps

#119

Post by habosa »

jcz wrote: post #109

The firestore security rules dsl [1] looks like it could become cumbersome as the number of edge cases increases. I've briefly used firebase realtime database json rules [2] in a side project, and while basic acl scenarios can be covered cleanly, rules quickly tangle without a full programming language. It's hard to check syntax, lint, test, and collaboratively edit. I believe this custom auth layer is best handled b…

The new rules language (which was already used by Cloud Storage) is a full programming language. It's not turing complete, but that's by design. Still, you can declare functions and do other complex things that were never possible with the Firebase Realtime Database JSON rules.

We're working on opening up the tools to work with the rules language so you can test and iterate more easily.

Re: Cloud Firestore: A New Document Database for Apps

#120

Post by itcmcgrath »

e12e wrote: post #106
habosa wrote: post #7

Earlier quoted context omitted.

You can store Blob data, but the maximum size of a single document is still 1MB. If you need to store larger blobs check out Cloud Storage for Firebase.

Could you share some of the reasoning behind arriving at a 1mb limit (why not 10mb or 512kb for example)?

Hard to explain externally, but it relates to RAM size allocation + throughput in the underlying distributed database system.
Post reply on HN