The other thing that is really nice about Firebase is that it pretty seamlessly integrates with GCP.
For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function. While it can get confusing sometimes, I think Firebase has done a good job "overlaying" their functionality set on top of GCP infrastructure, e.g. "Cloud Functions for Firebase" is really just a very thin layer on top of GCP Cloud Functions, Firebase Auth is basically the same thing as Google Identity Platform, etc. The author of the blog post sees that as a negative in some areas, but I don't.
FWIW, I looked through the authors list of Firebase "cons", and as someone who has used Firebase for years, none of those have really been a concern for me. My biggest concern is that there are areas of Firebase that have been calling out for love for years, particularly Firebase Auth, but they've gotten virtually no updates. Apparently nobody at Google sees making these straightforward but important improvements as a path toward getting a promotion.
> For example, with your #2, it's really, really easy to spin up a postgres DB on Google Cloud SQL and then access that DB from a Firebase Function
God no. The last time I checked, Firebase functions had intensively bad latency times for me. So bad that I decided to learn AWS Lambdas to get my work done. And yes, Lambda just blew Firebase and GCP functions out of the water.
[cloud functions for firebase manager] Lambda is indeed an innovative and solid product. Cloud functions for firebase has been getting a lot better recently too!
The biggest innovations lately has been our release of v2. V2 is built on Run and can support concurrent executions in the same container. This dramatically reduces the number of cold starts, and makes min instances reservations even cheaper if you want to eliminate cold starts for a given workload. Plus, Firebase lets you configure CPU separately from memory in V2, so you can give functions extra oomph if they need it. Docs are at [1]
Finally, Firestore’s SDK was slower than we liked in GCF so we’ve done a number of improvements there. About half a year ago we redesigned the SDK so we could lazy load the networking layer. This lets you handle Firestore events without loading the bulk of the SDK. We have a more extreme update in the works that will let you configure the Firestore SDK to prefer REST over gRPC so you can avoid heavy dependencies in latency sensitive/event driven environments like GCF.
I don't know when you tried this, but I don't think this is valid anymore:
1. If cold start times are a big deal, you can now set a minimum number of instances with Cloud Functions so they don't scale to 0. You can also now set concurrency on Cloud Functions so one function can run multiple requests simultaneously on a single function.
2. There are tons of other serverless options if you want to, say, have a Firebase front end but a backend API served in your language of choice that uses the Firebase Admin API to do whatever you want, e.g. App Engine or Cloud Run.
What I mean is mobile push notification.
Once I felt tempted to replace FCM with nats.io, turned out there were several cases need to handled. Oh well, back to FCM. At least, it's free.
Firebase is super convenient and works very well for the most part but my heart races every time I receive an e-mail from them. A silly mistake can cost you so much money and they tend to word the e-mails strongly.
> A silly mistake can cost you so much money and they tend to word the e-mails strongly.
They tend to word emails strongly to affect action.
As for the cost overruns: I don't know anyone who wrote one of those blog posts (or emailed support) who didn't get their bill refunded.
We can argue about spending caps or hard limits (which people generally dislike for their production apps), but the people side of the business is (or at least was) solid.
Source: worded emails strongly to affect action at Firebase and refunded a number of bills.
I am not convinced it is: frameworks on nodejs, ruby, php etc. can
give you most of it pretty simply for less expended
hours. For any project that doesn’t care
about webscaling:
which is
99%
Sure, you can do everything yourself but when you use Firebase all that is no longer your concern. It works as if you are interacting with 3rd party API, which means you only care about the request working and you don't care how exactly they are working behind the scenes which means you care about the actual stuff you are building.
Firebase does have some issues but the core premise is solid and IMHO everything will be like that as we go forward.
I am not sure doing this yourself is that problematic. You can get a managed postgres - and that is most of the ops work done. The rest is npm i this/that. The effort is approximately the same as the effort go get to know firebase.
I might be speaking as a jack of all trade so it seems easier to me. For a frontend only dev who needs a backend it might be different.
This is the main selling point of Supabase. Indeed, sometimes you don't need SQL. But in most cases you need SQL. Or you make awkward Firestore workarounds that are prone to introduce bugs and will definitely introduce complexity.
2. Database? Firebase Cloud Firestore. Sometimes, you don't need SQL.
3. Push notification? Firebase Cloud Messaging
4. File storage? Firebase Cloud Storage
All of my needs are served by single platform. Seems like Supabase handles all of them, except #3. Let's try :)