Firebase justifies its existence by serving as a customer acquisition vehicle for GCP. This is actually quite valuable given the huge marketing costs required to get a new enterprise cloud customer.

You're likely concerned about the precedent of Facebook shutting down Parse back in the day, leaving many projects stranded. Facebook though had no real commercial interest in cloud services back then.

They didn't shut down Parse though. You just had to self-host it. But somehow when Big Tech drops support for anything, people just migrate out of it for no reason and it becomes a self-fulfilling prophecy. Like Flutter careers are completely dead in the water now. One of my businesses has been running on Parse Server for half a decade and there's still updates on Parse. And despite being "dead", I still find Parse easier to code with than Firebase, though Supabase is now the favored option.

Fair point. But only a small minority of back end as a service users are comfortable with self hosting something like Parse.

Enterprises really like having someone to sue when things go wrong. And indie devs who pick BaaS offerings do so in large part to avoid the hassle of self hosting.

A bit off topic, but I wrote a guide to do this on Herok for anyone curious: https://smuzani.medium.com/setting-up-a-mobile-backend-serve...

I'm not sure if it's still valid but it's not too hard, and still much easier to maintain than dealing with AWS. I have basic AWS proficiency, but it's still good to have Heroku to not think about it.

Why are flutter careers dead?

Google laid off the Flutter team. They still seem to be releasing Flutter announcements but it's slow.

One big part of Flutter was that it was a hedge against Java lawsuits back in the day. The other was that it was experimenting with some mobile code, like designing it around lifecycles and all the async UI. But now the same paradigms have been adopted by iOS and Android.

Unlike BE, mobile moves quite quickly too; the last few years have been deprecating a lot of things like push notification security and file access. Mostly to deal with dark patterns. So a platform that isn't in active maintenance tends to fall apart quickly like we've seen with many mobile libraries, Cordova, etc.

It's a brilliant on-ramp for that, too, with high free usage caps that let you get projects up and running at no cost.

Firebase hosting only charges you when an actual thing you've deployed starts getting significant usage. It's a terrific option for small devs who still want custom domains, backend data, and the freedom to code in JS/TS in the browser.

Yeah but if you need features like Cloud Functions or SMS auth you have to give your credit card... with no spending limit... and the standard practice is to expose your firebase creds on the client... and their stated stance is its better to let you get attacked and then maybe waive the charges than to interrupt service to your site for a few hours... lol. Your recourse is to go viral on social media and get them to forgive the debt.

As a small dev firebase is horrifying.

It's annoying, but I'm not aware of anywhere you can get SMS auth without similar issues? Would love to learn if there are any.

Supabase does. It has a spending cap, so you won't wake up to a 100k bill if you get hacked. An app I recently consulted for used fireabase SMS auth. Someone spammed their sign-in page and they were hit with multiple 4-figure charges. Firebase refuses to refund of course. Its a great model until it really, really isn't.

For big companies like this, I like to go look at the activity on sdks and related projects. Typically activity will flat line before a sun setting announcement is made. Its hard to say how much lead time that buys you, but I have found it a useful barometer.

It seems like the firebase repos have had a fair amount of activity.

https://github.com/orgs/firebase/repositories

I don't see Google ending firebase anytime soon, but I don't like building inside of closed systems anymore.

It's very very difficult to migrate to a different service provider. Since Firebase is ultimately closed source, it's not your app. Your sharing it with Google.

Running a custom solution with Render(Heroku, etc) takes a bit more effort, but it's mine. I can actually open source it. I have more control.

For my current project I went from Firebase, to Superbase and settled on Django. I have some fairly complex logic and supabase just wasn't cutting it.

They just launched https://firebase.studio

Literally yesterday a friend linked the announcement of Firebase Studio with AI building of apps on Instagram: https://www.instagram.com/reel/DIRCBFCyk4X/?igsh=OHlraW5jYWt...

Which is quite different

What's quite different?

The original Firebase and what Google is calling Firebase Studio

It is still used a lot by many hundreds of corporations and likely makes them profit, so I would assume yes.

We use it too, but anything that requires actual funds, we would migrate to AWS or refactor.

Like we'd use to allow PMs to change banners/copy on the fly, but Supabase is better. It does RAG but Supabase does that better too. Firebase functions are really good for prototyping, but once it starts to cost money, we move it to AWS. It's good for feature flagging, and we moved that to Growthbook. Analytics started on Firebase and were moved to open source so we'd own the data. The only thing they do well is Crashlytics and that's free.

If everyone was as bad a customer as us, I would assume they're in trouble.

Unfortunately a lot of people have trust issues with Google. We don't want them controlling data and certainly nothing as core as functions, DB, and feature flagging. Then when people don't use these things, Google kills it real fast.

I suppose, but firebase is used in some applications, though of course a lot of them are just during testing, so assuming everyone was not like you they would make profit, but assuming a mix, they would make only a bit of profit, so it would be more like a small side project/nice feature that google provides that makes them a little bit of money.