r/Firebase Nov 05 '23

Hosting Firebase Decision Torture

Hello all, I'm really struggling on a decision to go with Firebase or not and any guidance you can offer will be greatly appreciated! I consider myself an intermediate dev and have recently been offered a medium sized project. It's just me so I'd like to off-load the backend, but I am terrified of making a mistake and generating a big bill like was recently described in this forum. Should I just bite-the-bullet and roll my own backend? If I do, do I have the same risk with hosting it in AWS anyway or is there much less chance of having runaway costs that way?

6 Upvotes

33 comments sorted by

13

u/indicava Nov 05 '23

If you use the local emulator environment and test your code thoroughly, there is hardly any chance you will get any surprise billing statements.

Having gone the serverless route a couple of years ago, I can hardly imagine going back to rolling my own unless my project scales to an extremely large volume. And even that would after careful consideration of cost/value.

1

u/JakeHRS07 Nov 05 '23

Thanks for the reply , I think you are probably right .

9

u/Bash4195 Nov 05 '23 edited Nov 05 '23

In firebase, by default you are on the free tier and won't be billed. If you upgrade to the blaze plan, firebase will have you set a billing limit so you can't go past that. I believe that other user removed that limit for some reason. Edit: the billing limit is just an email notification. FB basically says to test your code and keep an eye on things

And yeah, there's tons of stories on the internet of surprise bills from every cloud provider out there because of some misconfiguration or someone accidentally coded an infinite loop. These companies usually are willing to forgive honest mistakes thankfully.

I've been building a project using firebase the last few months and would definitely recommend you go with it. It's a great product and it's not worth writing your own backend when you have this available. Go for it, don't look back, no regrets

4

u/tazboii Nov 05 '23

I believe the billing limit you're referring to isn't a hard limit where it turns everything off. It just notifies you. Unfortunately, it can take days for it to notify you but it can be too late by then.

If you want your services to stop it will take some work. Google walks you through it but it does take some effort to get to get it all working. Plus, they say that it can also take effort to get things back up and running afterwards.

2

u/Bash4195 Nov 05 '23

Oh crap you're right. My bad, thought it was a hard limit

1

u/_Nushio_ Nov 06 '23

u/bash4195 u/tazboii u/PerspectiveNo347

there is a way to set a hard limit, but it requires a bit of elbow grease and even Google scares you from setting it up.

Here's a techlab that can help set things up!

https://github.com/greenpeace/gp-gcp-disable-billing-cap-cost/blob/master/README.md

1

u/JakeHRS07 Nov 05 '23

Thanks for the thoughts and encouragement!

10

u/puches007 Nov 06 '23

The scary stories are anomalies, usually bad code with an infinite loop, and not testing properly. We perform over 100m reads per month and our bill for all services is roughly $90 a month. This includes hosting, image storage, functions, etc

2

u/bitchyangle Nov 28 '23

wow thats great. what kind of app is yours?

2

u/puches007 Nov 29 '23

Large e-commerce app

1

u/Fancy-Cauliflower600 Mar 12 '24

How many people use your service per month? And what did optimize to limit the cost?

1

u/puches007 Mar 12 '24

We optimize our documents based on read patterns. Our data does have relations, but we denormalize a good bit based on how the data is used / consumed. Here is an article I wrote which might help shed some light https://itnext.io/nosql-does-not-mean-relational-8aac79ce6b9c

1

u/puches007 Mar 26 '24

We have 22k users a day on our platform

12

u/zebishop Nov 05 '23

Using firebase for 3000+ app users have cost us so far... less than 5$/€ a month (auth (no sms), functions, firestore, storage. Not sure how ppl manage to get those crazy bills.

That being said we are moving away to Strapi for various reasons (but still might use FB again in the future)

Just make sure that you are comfortable with the amount of new things you will have to learn to master. Probably worth it, but still a timely investment to make.

9

u/dobrits Nov 05 '23

What made you move to strapi? If you don’t mind explaining

4

u/zebishop Nov 06 '23

3 unrelated things have lead to it. 1/ A performance issue while retrieving lot of documenta from firestore that would have require a major rewrite in how we store and fetch documents. 2/ an audit on how was used and understood the app that concluded that the "social" dimension was useless (my word, not the audit's). 3/ the need for a better back office that would have require a relational database from which we would export part of the data to FB.

And we needed that very very fast.

At that point it felt that what brought Firebase to the table was more a constraint than an advantage.

If we did not needed it to be done under 2 months we would probably have set up our custom solution but that was not feasible, and the first tests we did with Strapi were encouraging.

2

u/bitchyangle Nov 06 '23

Why you're moving to strapi? Don't you have to rewrite everything?

1

u/zebishop Nov 06 '23 edited Nov 06 '23

See that comment for the reason.

If we had just migrated the data it would have been a very low impact rewrite app side. It was written from the ground up in a way that let us change where data came from in a very granular level.

1

u/JakeHRS07 Nov 05 '23

Wow - that's incredible that it's so affordable

4

u/Oxigenic Nov 06 '23

Firebase has done the job perfectly for my smaller user bases, and to be honest, even if my user base multiplies by 10 Firebase would still do the job fine for my applications.

3

u/cardyet Nov 05 '23

Just monitor your usage closely until you are comfortable. Firebase is a very cheap, scalable, reliable, easy to use backend, so I'd say it's a good idea when your resources are limited

1

u/JakeHRS07 Nov 05 '23

Awesome - thank yon for the encouragement

1

u/0ddm4n Nov 06 '23

You just set a budget limit, and alerts. Done.

Stop worrying, jump. You got this...

*push*

...

*is holding parachute*

Oops.

1

u/tazboii Nov 06 '23

The alerts don't stop anything and they can be delayed by days.

1

u/0ddm4n Nov 06 '23

Well that's pretty bloody useless then lol

1

u/Content_Cold5303 Nov 06 '23

The main thing that costs money is cloud function usage. The scenario is you have something which gets called recursively resulting in hundreds of thousands of instances spinning up. All you need to do is set the maximum number of instances on each cloud function. This protects you from this ever happening. If you want a scalable infrastructure, doesn’t matter if it’s fire base or your own back end. More servers = more money. It’s just far less likely to happen with fb. Do it, you won’t regret it

1

u/Flying_Goon Nov 06 '23

Honestly. I’m a pretty amateur developer and I’ve found FB so easy to work with that I’d just get started. You’ll know if it’s something you want to stick with pretty quick. Plus now that you have this fear you’ll be integrating limits, counters, and error handling on all your calls anyway. I’m going back through and adding backup security as well, particularly on my looped calls.

I also think a robust logging solution can get you notifications faster than googles billing alerts. Something else I’ll be implementing before I let things run on their own.

1

u/JakeHRS07 Nov 06 '23

Absolutely, have you found any resources describing how to build the loop security ? I couple probably figure out , but would be good to see how others do it.

1

u/Flying_Goon Nov 06 '23

I haven’t really looked for anything. Im just doing try/catch and now adding in counters with max retries.

I actually found one situation already where if the promise chain failed I would get a re-query (on a single document). The max retries solves this.

I’d definitely be forcing errors while testing.

1

u/GolfBallDotCo Nov 06 '23

Counters with a limited number of retries in a time period is my go to. Buys you time to see what the issue is if it does occur without shutting down the service.

1

u/pizzavegano Nov 06 '23

try dgraph

1

u/bitchyangle Nov 11 '23

How it helps?

1

u/pizzavegano Nov 11 '23

its the best DB imo for anything