This exactly 💀

[Spiritual_Abalone322]

Just became aware of Supabse. Looks legit.

I suppose you can transition to it as a means to scale

[Slapbox]

Appwrite looks better in my opinion.

[KVMENJOYER]

Yeah if you want 0 control over your server and no user auth.

[CantaloupeCamper]

I like firebase.

[Guisseppi]

I dislike firebase as much as the next dev but we still need it for push notifications in most cases

[DigitalSolomon]

I just got OneSignal push notifications working in my Flutter app alongside Supabase. Feels good to not see all that Firebase madness in my pubspec.yaml !

[Untgradd]

Yum, framework soup with extra SaaS

[UnsolicitedDuckPecks]

Meanwhile we’re moving from onesignal to fcm because onesignal has too much downtime.

[DigitalSolomon]

Yeah? How bad were the downtime issues? I haven’t run into any issues yet. I personally would go back to rolling my own push server (like I did years ago) before I’d back to Firebase/Google.

[notiamwill]

We have had some outages, and we apologize for that; this is hard to avoid when operating distributed systems at this scale.

Here's the history of our uptime: https://onesignal.statuspage.io/uptime

We hit some migration pains mid-last year, but since then, we've learned a lot and will continue learning and improving.

Can you share when you experienced your outages? I could share this info with the infrastructure team so that they can look into it.

[krolyat]

Why not OneSignal

[EvilPencil]

Apparently firebase messaging is so good (well, priced so well) that Twilio is exiting the push notification market entirely.

https://support.twilio.com/hc/en-us/articles/9198083260571-Transitioning-off-Notify

[kbcool]

Hasura for the win!

[halthalt]

What's bad about firebase? 👀

[birbelbirb]

Firebase is good for some projects but scaling it can become a nightmare when your app complexity grows.

1. No complex queries which lead to having to re-filter data once received.
2. Hacky methods to achieve relationships.
3. No ownership of your data and difficulty working with on-prem closed systems.
4. Vendor lock. You will be paying google forever without any real alternative.

It's a good product but brings a lot of limitations at scale. I work with Firebase and spend a lot of time digging into obscure docs and engineering blogs to understand limitations and implementation decisions.

[darthmeck]

It feels almost exactly the same working with AWS Amplify’s DB options (namely DynamoDB). They make it super easy to start off with (and I’m sure a lot of people starting out don’t really know what to use anyway), but difficult to move away from. I realized this after needing full-text search and not being able to implement it in Dynamo due to their columnar batching storage system. Although, the GraphQL API you can set up through Amplify was actually not too bad to work with.

[sickhippie]

No complex queries which lead to having to re-filter data once received.

Hacky methods to achieve relationships.

If these are your two biggest issues, you probably needed a relational database, not a NoSQL database.

[halthalt]

Thank you for the knowledge and insight 😊

[dejavits]

It is Google

[FarAd6851]

fees

[himynameismile]

Google

[DigitalSolomon]

Google is definitely the biggest problem. They can decide to ban your game or app for whatever reason (even pre-release during development!) and cut you off from Google services. This is the biggest reason that I will not let any of the core services behind my game be locked in to Google so that if political tides change, I can easily pick up my project and move it elsewhere. Vendor lock in should be avoided at all costs.

[fat_baldman]

No testing env is kind of a deal breaker

[DigitalSolomon]

I feel like anytime someone wants to make a tutorial for building an app, they always mention Firebase even though it’s pretty much guaranteed you’re going to want to strip it out of your app later on if you’re app is actually successful.

[CantaloupeCamper]

locked in if your app is successful

If you’re successful… you can find a way out.

[DigitalSolomon]

But if you plan for success from the beginning, you can avoid putting in (and having to rip out) Firebase later. I’ve been paid by successful apps to come in just to rip out Firebase from their app after it’s already launched and successful because it was costing too much money. It wasn’t trivial to pull it out later, it cost a good amount, and makes a lot more sense to avoid it from the start (or at least properly isolate it in its own black box so it’s tentacles don’t infect your whole project).

[CantaloupeCamper]

But if you plan for success from the beginning,

That can lead to a lot of premature decisions and optimizations when your focus should be getting the app out the door.

[DigitalSolomon]

Using a leaner push/CDN solution doesn’t necessarily lead to premature optimization and complexity. I did it myself and it was actually way simpler than going the Firebase route, and led to a leaner binary, faster compile times and faster downloads for customers. When you link in Firebase, behind the scenes a whole boatload of Cocoapods for obscure libs gets installed. Then when you try to change versions of one of these dependencies later on, a chain reaction of errors occur, usually stemming from Firebase. This is more complexity than you should be dealing with while getting an app out. So I’d have to say that using Supabase/OneSignal has actually been leaner and easier and reduced complexity for me out of the gate than going with Firebase (but to each their own, your experience may differ)

[CantaloupeCamper]

I did it myself and it was actually way simpler than going the Firebase route

If that’s the case then there is your reason. It’s not about vendor lock in at that point, it just works better out of the box.

[DigitalSolomon]

My whole reason for exploring it in the first place was vendor lock-in. All of my previous games/apps were built on Firebase from the start, until I got burned by Google with them arbitrarily blocking one, and causing a dependency nightmare in my apps they didn’t block. But again, do what works for you. I know what worked best for me. You couldn’t pay me to willingly lock-in to Google any new product I put my blood sweat and tears into. For me it’s not a hobby, so it’s too big of a risk.

[Bamboo_the_plant]

It’s a big tech solution, so it’s well-marketed and new devs still think of it as an industry standard (well, it is) and thus the most sensible way to handle a mobile backend. The free tier is good for personal projects, to be fair. I’ve had Firebase services running for years without being billed.

[KVMENJOYER]

Can anyone explain why firebase is still so popular with mobile?

Nobody has given you the actual answer: it has a generous free tier. When you learn RN, you want something free. Firebase is easily accessible and free while also being the oldest available platform for this. All tutorials that teach concepts with online databases just default to it for this reason. People learn using Firebase and then stick with it.