Supabase is about to solve Flutterflow's biggest problem

[@fabien8876]

Flutterflow is working on a better intégration of supabase.can t wait

[@AndrewBurchfield]

I’ve never related to a video more! Thank you for your style and delivery and creative structure!

[@johnckealy]

Thank you!

[@EdoardoCalderale]

Thank you for the suggestions!

[@mazenalsakkaf]

Many thanks, John.

[@tulasireddy6557]

Appwrite is very nice ❤❤

[@molefiramontseng7538]

Algolia + supabase will do for me❤

[@niyonda_clothing]

Insightful.

[@niyonda_clothing]

I would like to ask if you can help put me through how to integrate a USSD API into my flutterflow app.

[@johnckealy]

kealy.studio 🙂

[@GeorgeDicu-hs5yp]

how the heck its overpriced?? have you seend the prices?? reads are 0.03 pe 100.000 doc reads..so at 1milion read per day its 0.03 (us-central1 region) that is $0.3 per day and $9 per month...so tell me, did you read the documentstion before this video? How is 30 milions Reads pe month at $9 expensive??

[@squarkyt]

I’d imagine it’s more about it being nosql

[@theslongest]

Thinking Firestore is underwhelming or overpriced? Sounds more like a skill issue-you're probably just using it wrong

[@techjandro]

Yeah, it depends on how “good/bad” implemented it is, which is true for other similar services as well but it’s more likely to happen in Firebase due to its nature, also, because the lack of a f*ckng (sorry) pricing gap that makes developers to feel more terrified of using Firestore.

[@Mhddhn]

Of course, Firebase is expensive, and it’s not a question of skills. Imagine you create an application that displays a list of posts. If your app is heavily used, each post viewed will count as a read. So, with thousands of users, and if each person views hundreds of posts per month, do the math: you’ll see how Firebase becomes unsuitable for certain types of projects. And that’s not even counting the cost of writing and deleting data. Maybe you’re used to developing static applications with single elements. But as soon as you handle lists of objects, you’ll understand the issue.

[@theslongest]

@@techjandro I think you meant 'cap' instead of 'gap.' You can easily set up a function to stop service at a certain cap, and there's even a Firebase extension called 'auto-stop billing' to make this easy. These issues mostly don’t exist if you know the right tools, which is why they're often just skill-related challenges. That said, platforms like FlutterFlow can sometimes attract newer tech users, making these challenges more common.

[@theslongest]

@@Mhddhn Sounds like another skill issue 😉 Comments are too short for a full answer, but in your scenario, you can optimize by modeling data around the use case or leveraging Firestore Data Bundles to reduce reads.

[@techjandro]

@@theslongest ​​⁠yeah sorry, I meant cap, and yes, you are correct about the stop billing function but since it depends on other GCloud services and turns off ALL SERVICES (because it’s turning on the billing account, not the actual services) in the account and it’s not immediate or very intuitive (for most beginners in Firebase or gcloud) - but well, also very recently I was more aware of vendor locking etc so Firebase started to look a little bit like an option for MVP etc instead of production ready, but hey! A really Firebase lover myself, it just does make more sense for me and my reality/projects nature to go for similar alternatives, but really like using it. In any case, I mostly agree with the skill issue here.