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

151–160 of 174 posts

Re: Cloud Firestore: A New Document Database for Apps

#151

Post by ec109685 »

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…

While I know this is a beta and you’re solving a difficult technical problem, some of the limitations are concernig. With a system like dynamo, you can in most cases pay your way out of bottlenecks.

It would be nice to develop a way in Firestore for users to be able to pay for the number of shards assigned to their workload to reduce relatively artificial limits such as write limits within collections and index update rate.

That way, developers wouldn’t have to plan to leave the platform if their app is successful.

Re: Cloud Firestore: A New Document Database for Apps

#152

Post by ben75011 »

Having a consistent relational db background, I always feel a bit lost about the patterns provided to associate models in no-sql land. Firebase db was 'weird' when it came to associations, don't see that much changes here. The feature is available, but... Fire store provide 3 ways to do so, but why ? Going through the docs the results/benefits for each patterns remains unclear, the way to query each of those is not really understandable reading the docs. is this state will remains or is it a field that is potentially to be improved in the next releases ?

Re: Cloud Firestore: A New Document Database for Apps

#153

Post by Kiro »

jamest wrote: post #131
insomniacity wrote: post #77

Earlier quoted context omitted.

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?

(Some quick context for those not aware of the initial incident: In May we fixed two bugs in our pricing pipeline that caused some users to see price increases. Bug 1: we under-reported bandwidth (in particular SSL overhead) Bug 2: we were not enforcing quotas for all accounts. For most users, the fixes had little-to-no impact. For a few users who were using the Realtime Database with large volumes of small reads and…

> You could mitigate this impact by updating your client code

Where can I read about this?

Re: Cloud Firestore: A New Document Database for Apps

#154

Post by ben75011 »

ben75011 wrote: post #152

Having a consistent relational db background, I always feel a bit lost about the patterns provided to associate models in no-sql land. Firebase db was 'weird' when it came to associations, don't see that much changes here. The feature is available, but... Fire store provide 3 ways to do so, but why ? Going through the docs the results/benefits for each patterns remains unclear, the way to query each of those is not r…

It might just be me misinterpreting your example, but having created the required records to run the following command ('var messageRef = db.collection('rooms').doc('roomA').collection('messages').doc('message1');'), i don't see no results. Or people is expected to understand that 'message1' stands for an object ?

Re: Cloud Firestore: A New Document Database for Apps

#155

Post by hmexx »

marksomnian wrote: post #149
alberteinstein wrote: post #148

Earlier quoted context omitted.

Sorry about that, we have deprecated local feature, but yeah docs lag behind. Please login to https://dashboard.hasura.io and create a free trial project.

"but runs on your own infrastructure, off of a traditional RDBMS" "exactly what you're asking about" "deprecated local feature" Eh?

yeah. The search continues.

the following 3 have some potential:

https://feathersjs.com/and postgraphile https://postgrest.com/en/v4.3/ https://www.npmjs.com/package/postgraphile

Re: Cloud Firestore: A New Document Database for Apps

#156

Post by onion2k »

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.

how much code will you need to rewrite?

If you're concerned that a service might shut down then you need to architect your application with that in mind, in which case how much of a rewrite is necessary is essentially up to you. Usually there's a tradeoff between going fast and engineering solutions that will work in the long term. Most startups never get to the stage where they need to swap out a service, so closely tying your application to a service is probably OK at the start.

If the service that shuts down is reasonably popular though it's likely there'll be very little code to change. API-compatible competitors will pop up to replace it. It happened when Parse closed.

Re: Cloud Firestore: A New Document Database for Apps

#157

Post by fiokoden »

Just never use Google for building applications.

They have invested heavily over the lifetime of the company in avoiding providing support. That reputation can never be revived.

Google does not have direct customer support in its DNA, it has the opposite, whatever that is.

They have not demonstrated relentless commitment to being available to resolve issues, and nothing matters more than this if you've bet your company on their platform.

If something goes really wrong. Amazon has your back and you'll find someone who'll listen who has the power to resolve it. Google, you're stuffed. If you've built you're business around that thing that went wrong, well time for regret.

Re: Cloud Firestore: A New Document Database for Apps

#158

Post by Kiro »

alexnewman wrote: post #133

Why anyone still uses firebase when there's trivial to get running OSS ways of getting this done I'll never understand. People think stuff like this makes time to development smaller, I say it increases it deceptively

I'm a one-man shop and the less time I need to spend with servers the better. The Firebase + Google Cloud Functions approach has served me well.

Re: Cloud Firestore: A New Document Database for Apps

#159

Post by ryanbrunner »

onion2k wrote: post #156
stefano wrote: post #87

Earlier quoted context omitted.

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.

how much code will you need to rewrite? If you're concerned that a service might shut down then you need to architect your application with that in mind, in which case how much of a rewrite is necessary is essentially up to you. Usually there's a tradeoff between going fast and engineering solutions that will work in the long term. Most startups never get to the stage where they need to swap out a service, so closely…

The thing is, oftentimes these closed source database solutions aren't appreciably faster than choosing a managed solution that uses existing technology, like a hosted Postgres / MongoDB / whatever provider. In those cases your switching cost is vastly reduced, it's essentially a purely operational concern and your code doesn't need to change at all.

Re: Cloud Firestore: A New Document Database for Apps

#160

Post by Cthulhu_ »

mbleigh wrote: post #129
mjw1007 wrote: post #128

Earlier quoted context omitted.

Perhaps you could consider persuading the powers that be to make a loud public commitment. After all, if they are truly confident, there should be little cost in doing so.

We announced the product, that's a loud public commitment. Once it reaches general availability, it will be covered by the Cloud deprecation policy requiring a minimum of one year notice for deprecation. I'm not sure what other guarantees would even make sense to offer. If anything, I'd look at this announcement as ongoing proof in the magnitude of investment Google is making in Firebase and Cloud.

I'd guess a forward commitment, like a LTS version? That would probably have an adverse effect though, since you'd be the only provider that goes (e.g.) "We will support this product for at least three years from now", implying (to people making Decisions) you'd pull the plug after three years.

Maybe publish a long term (5+ year) plan / roadmap? idk.

Post reply on HN