Do you have some more to read about that? Sounds interesting but I'm now confused as to what FireBase is/does.

As other comment stated, Firebase does a lot.

First and foremost it is client side SDK's (web, mobile) for their database products, their newest being Firestore that provides better query capabilities compared to their original Firebase Realtime database (while still offering real-time capabilities).

Along with that is Firebase Authentication, which manages user accounts and authentication.

The real magic comes in with Cloud Functions (their version of Lambda) which allows for hooks in to all sorts of events occurring from usage of these database and authentication products (and other cloud services).

Hook into database writes, updates, deletes, user creation, Google Cloud's pub-sub events and many more. They also offer static website hosting as well as hooking website serving into cloud functions (for server side code execution).

In the context of a website, all of these work together to allow for usage of the JAMstack[0] architecture which decreases your infrastructure resources you need to manage and cost.

[0] https://jamstack.org/

Firebase does a lot of stuff. Originally it was a small company that focused on providing a real-time JSON-like backend store for web apps. But then they got bought by Google and seem to have evolved into Google's answer to a lot of AWS services, ie hosting, real-time DB, serverless, and probably more I'm not aware of.

I've often looked at and played with Firebase since it does so much of what I need to back a React Native-based app for simple mobile games and utilities. I always end up talking myself out of it due to Google's history of pulling the plug on (what seem to an outsider to be) perfectly good, stable products that wouldn't do any harm to keep around indefinitely.

As a hobbyist, I wouldn't have the time or motivation to completely rewrite a project if that happened, which would be necessary since a Firebase app (like a heavily AWS-integrated serverless app) is not just technologically but architecturally tied to that environment.

This seems more applicable to consumer products, not business / cloud services, though I imagine I might be overlooking something.

That's a fair observation. I do go back and forth but in the end it's enough to swing me, in the principle-of-least-regret way.

It seems like a pretty reasonable concern to me. We can presume the odds are pretty low, yeah. But the consequences are very high - you would need to redesign and possibly rewrite in another language your entire application. People complained up a storm about Reader dying, but it was a 5min process to export your subscriptions and import into another web reader that had basically the same feature set. Conventional Linux hosting, or even Docker, could be pretty easily re-hosted as-is on any of hundreds of other places.

So what do you use as the backend for now?

I usually go with a Django or RoR monolith, something that I know I can run on a cheap DO droplet or similar, and while there's a fixed monthly cost it's reasonable and I can scale up with ease (albeit manually). If I were explicitly needing the realtime DB aspect I'd probably look to Phoenix with the same hardware approach.

It would be nice if there was a dead-simple Firebase-like tool you could self-host. ie just a single instance that you could point all your toy apps at to give them a little real-time persistence.

Around the time that Parse (mentioned by sibling) was killed and open sourced, a lot of open source Firebase-like solutions had sprung up, some of which are listed here: https://github.com/relatedcode/ParseAlternatives#open-source...

Parse was a Firebase competitor that got bought by Facebook and later open sourced, I don’t know if it’s dead simple though.

https://parseplatform.org/

For this purpose it does realtime database, faas, scheduling, pub/sub, authentication, file storage, notifications and web hosting.

Everything you need for a web or native app, and it's all integrated together rather well.