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.
Supabase (YC S20) – An open source Firebase alternative
321–330 of 374 posts
Re: Supabase (YC S20) – An open source Firebase alternative
#322To 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 :)
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
#323We 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
#324Earlier 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…
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
#325The 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…
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
#326It 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
#327Earlier 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…
Re: Supabase (YC S20) – An open source Firebase alternative
#328Earlier 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.
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
#329Earlier 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..
Re: Supabase (YC S20) – An open source Firebase alternative
#330Earlier 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.