Live data from Hacker News

Supabase (YC S20) – An open source Firebase alternative

supabase.io

321–330 of 374 posts

Re: Supabase (YC S20) – An open source Firebase alternative

#321

This looks to just be the "real time" DB? How is this different from using GraphQL subscriptions via Hasura/Postgraphile, or RethinkDB? Also, it seems like it's missing everything else that Firebase provides. Authentication, authorization, storage, hosting, etc. To me, Firebase's value prop is more than just a database.

AFAIK Firebase doesn't actually offer any real authorization do they? It was some time ago I last built a project with them, but I remember having to create a custom "roles" attribute in the Realtime DB for users.

Re: Supabase (YC S20) – An open source Firebase alternative

#322
post #183

To be a Firebase alternative, you would expect a full-stack solution; DB, Auth, Cloud Functions, Analytics...etc. That's the main selling point of Firebase. This just seems to be an Open-Source implementation of Firebase's " Realtime Database ", which is kind of superseded by the new " Firestore ", which is much more popular. However it's a smart business move, as many products are locked into the " Realtime Database…

That's true. See my comments here: https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)

I'm a consultant and I love the idea of having Postgres instead of NoSQL on the backend, coming from Amplify.

For me the MVP, before I could use it for my commercial projects, would be: DB+auth. At that point, I could switch - and probably would.

Also, kudos to you for being the diametric opposite of a 'useless' startup. Not only would I use this once I could, I'd talk it up to everyone in my space.

Re: Supabase (YC S20) – An open source Firebase alternative

#323
Guys, check out https://github.com/deepstreamIO - open source MIT - I've been a long time user and it works great. It's a typescript code base, very readable and straight forward, uses protocol buffers for messaging and uWebSockets.js for the websocket server (ultra fast). You get realtime records, pub/sub, events, rpc, fine grained permissions, http endpoints and basically you can hook up to any backend (currently there are connectors for postgres, rethinkdb, elastic and others).

We need more people to use it, cause the original developer is going on maintenance mode and we're trying to strengthen the community. It rocks!

Re: Supabase (YC S20) – An open source Firebase alternative

#324
post #309
post #185

Earlier quoted context omitted.

What are the pros/cons of using entirely different (siloed) databases with uniform permissions instead of a single database supporting granular permissions? Off the top of my head, I'd say security might be improved but ease of use may suffer. Interested in hearing other's thoughts on the matter.

The cons are inumerable. We've been down that road before and the whole world of business intelligence and enterprise data warehousing came out of it. When every functional unit has their own db, how do you answer questions of the business as a whole? How do you deal with data that multiple functional areas need? On top of that, managing a lot of small silos requires a lot more work and resources then the alternative…

One thing to note is that the singular database used for answering business questions is often not customer facing, and thus does not have as strong reliability guarantees (In my experience). Most of the business analytics happens asynchronously (etl pipelines everywhere).

I'm not sure how to avoid this. The need to answer business question favors a single, queryable DB whereas the need to keep applications siloed and abstracted away favors multiple application data stores.

Re: Supabase (YC S20) – An open source Firebase alternative

#325

The biggest feature I will be looking for in this is a true push to android mobile devices. It looks like you can use the subscribe function for this, but I'd need an android example to get up and running quickly. Right now it seems like firebase is the only game in town for that functionality unless you want to roll your own with websockets or some sort of MQ. Google also strongly encourages use of firebase for that…

You're correct that the Firebase Cloud Messaging is essentially required for Android push. As of Android 8, Google prevents background connections from being held open by apps, and requires FCM in order to wake up apps (eg: to receive a notification). This is documented here: https://developer.android.com/training/monitoring-device-sta...

If the app is already running (eg: in the foreground), then you can (and probably should) use your own non-FCM connection for sending messages or data.

Re: Supabase (YC S20) – An open source Firebase alternative

#326
If you’re looking for something with a few more features then I recently discovered https://appwrite.io

It includes database (Firestore), storage (Cloud Storage), users (Firebase Auth) and more, plus you can host it yourself. I haven’t used it myself yet but keeping a close eye on it.

Re: Supabase (YC S20) – An open source Firebase alternative

#327

Earlier quoted context omitted.

We started moving off "fat models" at my job and onto DDD (service methods, entities, etc.), and I have to say after a year I'm not a fan. Here are my beefs: 1. If you're not using models, it's a lot of work to stay fast. If you've got a Customer instance, and you want to get customer.orders, you've got a problem if it's not lazy. If it's a queryset, you get laziness for free, if it isn't you have to build it yoursel…

I think we're agreeing on the majority of this. We have not chucked DRF or Django auth or anything. We've just created service layers to take the business logic out of the API views, API serializers, and DB models. Each action looks like 1. Request arrives into the app, auth happens using DRF on the API view. This is all using Django & DRF built-ins. 2. In the API view: request data gets serialized using DRF serializ…

Got it, yeah that makes sense. At a previous job, we invested pretty heavily in model serializers, but yeah they’re bonkers slow. Thanks for weighing in, really nice to talk about this stuff with someone with a lot similar experience.

Re: Supabase (YC S20) – An open source Firebase alternative

#328

Earlier quoted context omitted.

That's true. See my comments here: https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)

I'm a consultant and I love the idea of having Postgres instead of NoSQL on the backend, coming from Amplify. For me the MVP, before I could use it for my commercial projects, would be: DB+auth. At that point, I could switch - and probably would. Also, kudos to you for being the diametric opposite of a 'useless' startup. Not only would I use this once I could, I'd talk it up to everyone in my space.

Thanks for your feedback. We hope to have a proper Auth system in place before our official launch in September.

We like building things that people will use. The number of features that Firebase offer is vast so it might take us some time, but we will get there and we’ll make sure we do it in a way that benefits the opensource community

Re: Supabase (YC S20) – An open source Firebase alternative

#329
post #243

Earlier quoted context omitted.

Amazon seem to be working on bringing Amplify up to the same standard as Firebase, and it's certainly getting there, so in the near-future there may be quite a few alternatives.

I wrote a master thesis where I compared several realtime database products. I promise you amplify is no where "getting there". It is a crippled version of firebase and there is no fix in sight. For example you cannot even do sort-queries with datastore or Amplify is not working with angular because they have broken typings since 9 months with no fix. And the list goes on..

Would love to read the thesis if you can share!

Re: Supabase (YC S20) – An open source Firebase alternative

#330

Earlier quoted context omitted.

I answered this over here: https://news.ycombinator.com/item?id=23320443 tldr: > We've been building furiously since January but (not surprisingly) we haven't yet reached feature parity. But we will :)

Sounds good. Would it make sense to put some info about your roadmap on your main marketing pages? There's pros and cons of that, but for positioning sake, I'd recommend it, and given that it's still an alpha, I think that mitigates the expectations of feature completeness.

Good idea. This post caught us off-guard but I’ll update the site as soon things settle down
Post reply on HN