35 thoughts on “How to NOT get a 30K Firebase Bill

  1. Your content is great as always. Mini case-studies like this are a fantastic way to implement several little features of angular, rxjs, & firestore into the bigger picture of a more thoughtful app architecture. For angular newbies like me, this is gold. You've outdone yourself on this one.

  2. I know this video is kind of old but what about implementing serverside rendering with for example NodeJS and just updating the value only once maybe every 10 seconds and then caching it. Maybe I'm missing something but shouldn't that also reduce the amount of calls to the database significantly? Because the server only needs to do one call to the database every 10 seconds and render the front end view with this information for the user.

  3. This example is NOT good but 100% wrong because we have a limitation in document size in the firestore. we don't store all transaction data in a single document, the size around 1MB per document please check first firestore documentation.

  4. Solution is wrong because it creates a incorrect sum if trigger onCreate is executed multiple times. See https://firebase.google.com/docs/functions/firestore-events?hl=en “Events are delivered at least once, but a single event may result in multiple function invocations. Avoid depending on exactly-once mechanics, and write idempotent functions.”

  5. You always make a great contents in such short amount of time. You're the best! Can you pleas make same video for this use case using flutter b/c i don't really know much about angular to get most out of it. Thanks in advance.

  6. Here is something I don't get: with traditional relational databases the consensus was to never ever access the DB from the frontend. But it seems like this is exactly what we are doing here. Isn't this a major security hole that allows users to write arbitrary data to the DB?

  7. Cloud looks dangerous, 30k dollar bill its above 150k reais (brl)

    Cant pay this in even 25 years #Brazil

  8. isn't possible to store a posgresql database with apache server on a common host server and synchronize it with flutter ?

  9. You are decoupling the code that adds a donation with the code that updates the aggregation. This is bad because your database will be in an inconsistent state until the cloud function runs.
    Probably, the best way to go about this would be to run the donation function in a transaction that both inserts a new donation and updates the aggregation document. This way, your database will always be in a consistent state.

  10. I always try to write cost-efficient code. Sometimes it takes more time in comparison to writing expensive code.

  11. For those which looking for a solution to store all data in a single document with Flutter:

    Firestore _firestore = Firestore.instance;
    String name = 'Frank';
    String email = '[email protected]';
    int id = 1;

    Map<String, Object> list = {id: {'name': name, email': email}};
    _firestore.collection('test_collection').document('test_document')

    .setData(list, merge: true).then((_){
    print('added successfully');
    });

    If you set merge to true, Firebase will not overwrite your existing data, rather it will create a new map field.

  12. Yea thats the problem of reactive subscribe thing. Its hard to understand. Easy way is to not use reactive . Do normal way…

  13. Great video. I could use your help on this topic because my firm is building a social chat app with Flutter front end. We are debating on using Firebase or go with a traditional database model (MariaDB) on a bare metal server. Is there way to manage costs effectively with FIrebase for a user base of 500K users with 10-15K DAUs to start? This app could grow to 5 mm users with 1 mm DAUs. We would be using SMS authentication as part of the design. Thanks!

  14. as Danilo Fuchs suggested, It is better to use transaction to update aggregated donation counts & total, I think it is better that you put an annotation on the video about this

Leave a Reply

Your email address will not be published. Required fields are marked *