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

101–110 of 174 posts

Re: Cloud Firestore: A New Document Database for Apps

#101

Post by pritambarhate »

jamest wrote: post #95
pritambarhate wrote: post #57

Does 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 l…

Thanks for the clarification. I certainly feel better with the confirmation. I hope it will give some certainty to thousands of developers out there who decided to make Firebase Realtime Database a critical component of their product architecture.

Re: Cloud Firestore: A New Document Database for Apps

#102

Post by jopsen »

habosa wrote: post #39
adamonkey wrote: post #30

How is the pricing? Firebase Realtime Database is fairly expensive ($5/GB of storage per month), so it makes economic sense for developers to migrate to their own backend once they hit a certain scale. This is why third-party mobile backends are nowhere near the popularity of non-mobile backends with Google Cloud / AWS. Do you think $0.18 per 100000 writes solves this problem?

As you've noticed, the pricing model is totally different for Cloud Firestore. Link for others reading: https://firebase.google.com/docs/firestore/pricing If you're concerned about price per GB stored, Cloud Firestore will be much cheaper than Realtime Database (0.18/GiB/month). We evaluated many use cases when deciding on prices and we believe developers will be happy with the new model. However since Cloud Firestor…

So:

firebase firestore quick question: So the real-time features in firestore are not ideal for real-time text editors and chats. But saving documents from firebase after to user has left is perhaps a good middle ground.

Would firestore charge read for each reader that's listening in real-time when a document is updated?

Re: Cloud Firestore: A New Document Database for Apps

#103

Post by habosa »

jopsen wrote: post #102
habosa wrote: post #39

Earlier quoted context omitted.

As you've noticed, the pricing model is totally different for Cloud Firestore. Link for others reading: https://firebase.google.com/docs/firestore/pricing If you're concerned about price per GB stored, Cloud Firestore will be much cheaper than Realtime Database (0.18/GiB/month). We evaluated many use cases when deciding on prices and we believe developers will be happy with the new model. However since Cloud Firestor…

So: firebase firestore quick question: So the real-time features in firestore are not ideal for real-time text editors and chats. But saving documents from firebase after to user has left is perhaps a good middle ground. Would firestore charge read for each reader that's listening in real-time when a document is updated?

I wouldn't say the difference is exactly that clear cut. Presence is a clear example of a situation where you want to use Realtime Database over Cloud Firestore. And you're right, for something that you would otherwise do "in memory" or use memcached/redis/etc Cloud Firestore may not be the right fit.

In my experience both databases are totally appropriate for a chat app. Even though in Cloud Firestore you will pay a document write for each new chat message, that's only $1.80 for a million chat messages and you get all the rich querying from the Cloud Firestore API.

Regarding your pricing question: https://firebase.google.com/docs/firestore/pricing#operation...

> When you listen to the results of a query, you are charged for a read each time a document in the result set is added or updated. You are also charged for a read when a document is removed from the result set because the document has changed. (In constrast, when a document is deleted, you are not charged for a read.)

Re: Cloud Firestore: A New Document Database for Apps

#104

Post by hmexx »

pcnix wrote: post #80
hmexx wrote: 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?!

You should check out Hasura ( https://hasura.io/ )! It is exactly what you're asking about. Disclaimer: I work at Hasura. Feel free to ask me anything you want to know about.

Woooo.. Interesting. I'm going to download it now and give it a whirl. Will get back to you with feedback (if you're interested).

Re: Cloud Firestore: A New Document Database for Apps

#105

Post by itcmcgrath »

nkw wrote: post #19

This is great. I had a feeling something like this was coming given most firebase people were pretty open about what the shortcomings of the Realtime DB were and AngularFire received some much needed attention to its database API last week. That said, I really hope there are plans for some full text search ability beyond the current suggestions[1]. I would very much like to ditch Elasticsearch in favor of db engine p…

Thanks for the feedback, this request is definitely been a frequent one. :)

Re: Cloud Firestore: A New Document Database for Apps

#106

Post by e12e »

habosa wrote: post #7
aphextron wrote: post #6

Earlier quoted context omitted.

Very exciting. I found this to be the one "missing piece" keeping me from being able to build a whole app on Firebase when checking it out earlier this year. One question though, will this support BLOBs like GridFS?

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

Re: Cloud Firestore: A New Document Database for Apps

#107

Post by steego »

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?

For their own sake, I hope the team gives this question attention and respect.

What sets Amazon apart from many other companies is their reputation for relentless customer service. Customers pay close attention to the quality of answer or lack of answers to questions like this one.

Every cloud company that asks us to invest our time in their proprietary API is asking us to trust them. If you violate one vocal customer's trust, we're going to notice. If you don't make things right, we're going to notice. Even before I read the article, I first read the comments to gauge the reception because I care more about the perception of trust before I even consider using something like this.

Customers don't always stop trusting companies for fair or valid reasons, but that doesn't matter. Trust is much more of a visceral thing than a cerebral thing.

So here's my question to other HN readers. What would Google need to do to improve its reputation for customer service? What would they need to do to make that commitment resonate with you on a visceral level?

Re: Cloud Firestore: A New Document Database for Apps

#108

Post by jonasb »

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…

The enhanced query capabilities are very much appreciated. I hope full-text search is in the works, since adding a 3rd party FTS engine adds quite a bit of complexity.

Re: Cloud Firestore: A New Document Database for Apps

#109

Post by jcz »

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 by allowing code with restricted api access and time constraints. The technical approach cloudflare used to implement its edge workers by embedding v8/js [3] would be perfect here.

[1] https://firebase.google.com/docs/firestore/security/get-star...

  example:
  service cloud.firestore {
    match /databases/{database}/documents {
      match /{document=**} {
        allow read, write: if false;
      }
    }
  }
[2] https://firebase.google.com/docs/database/security/

[3] https://blog.cloudflare.com/introducing-cloudflare-workers/

Re: Cloud Firestore: A New Document Database for Apps

#110

Post by euyyn »

mikelehen wrote: post #53
ibdknox wrote: post #45

Earlier quoted context omitted.

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

> OT conflict resolution as a layer on top of last-write wins

Can you link to somewhere where this layering is explained?

The www.firepad.io site has documentation on how to use the editor, but I'm interested in how "OT on top of last-write wins" is achieved.

Post reply on HN