If i'll do something, will let you know if you wish
It's mostly about communicating the intend and a testament to Firebase establishing this rather broad product category, i.e. DB + dashboard + auth + files + ... You could probably also call it "a bucket of generally useful stuff", just doesn't have the same ring :).
> create per-user (likely with some limit of total 10 or so instance) demo env - average sysadmin like me should be able to handle it.
Totally feasible. There are also kubernetes deployment manifests in the repo. That said, I don't mind the shared instance too much. There's pros and cons. Happy to chat more.
> If i'll do something, will let you know if you wish
Sure thing. Thanks!
Does this project have a different focus than Supabase regarding the features to be implemented?
Supabase: https://supabase.com/
It's just super weird to me to see something presented as a "Firebase alternative" without a single realtime data sync example on the homepage. Trailbase has one deep, deep down the docs and nothing is explained about the "subscribe" limitations. That's not a Firebase alternative, it's just a hosted database. That's like calling a Chromebook an "iPhone alternative" because it lets you access WhatsApp and Twitter just like an iPhone would.
ps. I haven't followed Supabase a lot so maybe they got on top of this since, but it was pretty disappointing to me back when they launched to much fanfare. Like the only realtime thing they had was a counter or something like that.
We likely agree that firebase is superb. But your criticism of using ‘alternative’ is unjust both in terms of the breadth of firebase, and why a competitor might target someone about to choose Firebase.
Either way, they are all rather broad products and many users only use subsets. Thanks for speaking up, appreciated.
Somehow I've always read "Firebase alternative" as "alternative to Firebase Realtime Database" but now I see that what Supabase & co mean is "stuff you can put on a server once and then you won't need to do any backend stuff anymore", ie the current positioning of the Firebase brand.
I stand corrected.
(sidenote, Google's Firebase acquisition has to be one of the best-executed devtool acquisitions right? Nobody would've been surprised if they had just gobbled Firebase up, spread the team across GCP, put the product on life support and after a year told customers to just move to GCP proper, somehow. Instead they realized that "GCP Easy Mode" was worth having a separate brand for and they executed excellently on that)
It’s insanely lean to get started. But at the end of the day, its GCP underneath with GCP billing (i.e. no spend caps). The easy mode UX, and the risk of real expenditure, sit in contradiction to each other. Of course, there a very generous free tier to placate that. But things like realtime need to be used with real cost considerations, and not frivolously once you need a feature only available on pay as you go.
laveur•8mo ago
aklemm•8mo ago
trailbase-alt•8mo ago
A Java/Kotlin client is certainly on the short-list. We recently added one for Swift. There are also clients for Dart, TypeScript, and C# in case you're more into cross-platform app development (Flutter, React Native, and Maui/Avalonia respectively)