Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase (YC S20) – An open source Firebase alternative

supabase.io

Post reply on HN
Print view View original

161–170 of 374 posts

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

#161

Post by rakoo »

mercer wrote: post #156
habosa wrote: post #149

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from. I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this: * Pick a…

I can't help but mention that I rather like the alternative approach of keeping steps 1-3, and using Phoenix LiveView (or C#'s Blazor?) for the rest. Not saying it's better or worse, but I quite like it.

If you don't pick a db, where do you store data ?

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

#162

Post by pm90 »

sshb wrote: post #95

Recently released similar thing for gRPC + Go + PostgreSQL stack: https://github.com/sashabaranov/pike/ Features include: • Generates CRUD operations for given entities • Generates SQL migration files • Gives developer full control after project is generated(nothing added on top of raw SQL/Go) • Minimal dependencies(basically lib/pq and grpc) • TLS out of the box

What the fuck. This is insanely cool!

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

#163

Post by databrecht »

InvOfSmallC wrote: post #119
databrecht wrote: post #82

Earlier quoted context omitted.

Did you check FaunaDB by any chance? I'm wondering whether their ABAC systems + UDFs would satisfy your needs.

I will check it thanks! Although the authentication seems too manual. That part I prefer firebase.

Thanks, that's valuable feedback :) We indeed are currently providing a lot of building blocks that can solve a wide range of scenarios but did not focus too much yet (until now) on providing easy out-of-the-box combinations of those building blocks that just solve a specific scenario.

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

#164

Post by time0ut »

pm90 wrote: post #153
habosa wrote: post #149

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from. I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this: * Pick a…

Maybe I am an old fart, but what’s wrong with the steps you mention? What would your ideal sequence of steps be? If the answer is “just call an api to handle your data” sure that works for POCs/Small apps. But I’m a bit hesitant to put all my businesses data inside a proprietary data store that I don’t control and which isn’t collocated with my app (Ie every data store request makes a round trip to the google server…

I've used Firebase for a couple MVPs. It is very fast to develop on. It makes it easy to get a web or mobile app up in a few hours once you know what you're doing. It is definitely possible to be that fast using other technologies, but the learning curve is higher.

When you're just experimenting, trying to find market fit and get something to stick, Firebase is a decent solution. I haven't tried anything sizeable on it though. Eventually, I'm sure we would've migrated if we were successful enough.

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

#165

Post by eatonphil »

pm90 wrote: post #153
habosa wrote: post #149

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from. I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this: * Pick a…

Maybe I am an old fart, but what’s wrong with the steps you mention? What would your ideal sequence of steps be? If the answer is “just call an api to handle your data” sure that works for POCs/Small apps. But I’m a bit hesitant to put all my businesses data inside a proprietary data store that I don’t control and which isn’t collocated with my app (Ie every data store request makes a round trip to the google server…

It's not bad doing it once. Furthermore I'd suggest you do it truly from scratch once just for the learning experience (no framework [Go makes this easy] or from TCP socket [synchronous with Python is easy]). However it's ridiculous going through the same sequence for every single app you build over a career. Nothing changes, it's all just boilerplate.

I don't want to ever write this sort of boilerplate code again, I want it generated from a DB schema or something similar [0]. There are better things to spend time on.

[0] https://news.ycombinator.com/item?id=23322300

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

#166

Post by beisner »

pm90 wrote: post #153
habosa wrote: post #149

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from. I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this: * Pick a…

Maybe I am an old fart, but what’s wrong with the steps you mention? What would your ideal sequence of steps be? If the answer is “just call an api to handle your data” sure that works for POCs/Small apps. But I’m a bit hesitant to put all my businesses data inside a proprietary data store that I don’t control and which isn’t collocated with my app (Ie every data store request makes a round trip to the google server…

Excellent for deploying small auxiliary apps that are not necessarily your company’s core competency, or a side project.

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

#167

Post by jimktrains2 »

eatonphil wrote: post #159

This is really interesting. I spent a while a few weeks ago looking around for a serious, open-source BaaS effort backed by... anyone. I've been influenced by code generators like xo/xo [0] and sqlboiler [1] recently (so you can have type-safe APIs and you still manage/own the resulting code). My bet is that you can generate an entire API _and_ basic CRUD browser UI from a db schema. I've been working on a code gener…

I built something a while ago call bam[0] that basically did that. You specces your application in an xml file and it built out the admin ui, orm code, and db schema. I took a bet on a soon to be dead framework and ultimately didn't have time to continue the project, but it worked pretty well.

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

#168

Post by databrecht »

rhlsthrm wrote: post #134
BiteCode_dev wrote: post #97

A bit of a plug, but if you wish for something that has the Postgres reliability, the taste of nosql but with strong typing and a json output a la graphql, give a try to edge db: https://edgedb.com The team behind it is awesome (one is a python core dev), and it's a FOSS, but they have been using it internally for some time.

I feel like this is close to what I'm looking for but not quite there in terms of minimal boilerplate backend. Basically what I want to do is write a GraphQL schema and have that be the ultimate source of truth. The schema then should generate the full DB (honestly I don't even care if it's SQL, NoSQL, etc. the idea is that part is abstracted away). Then the schema can generate fully typesafe queries for the front en…

I'm wondering how FaunaDB's GraphqL would suit you? It's basically: "drop in schema, get API". You can't do everything that you'll ever need yet but you can go quite far and the implementation of each query is efficient since every query is one query and thus one transaction, is backed by indexes that are automatically generated and finally we are quite suitable for GraphQL-like queries. (because those are a bit like tree-walking queries for which the 'Index-free Adjacency' concept in graph databases is very suitable and FaunaDB's References are quite similar. Although we're not a Graph database we don't have problems with huge graph-like joins because of that. besides that, the compatibility of our native FQL language made it ridiculously easy to generate an FQL query GraphQL queries)

If there is something missing in our GraphQL feature set, feedback is very welcome :).

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

#169

Post by phoenixdblack »

The thing that's really invaluable for me is the firebase javascrpt implementation. Saving the state in a web app and new Objects being addable/editable offline with firebase automatically synchronising when network is available with me doing absolutely NOTHING is absolutely insane. Having just the API isn't really going to cut it.

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

#170

Post by eatonphil »

jimktrains2 wrote: post #167
eatonphil wrote: post #159

This is really interesting. I spent a while a few weeks ago looking around for a serious, open-source BaaS effort backed by... anyone. I've been influenced by code generators like xo/xo [0] and sqlboiler [1] recently (so you can have type-safe APIs and you still manage/own the resulting code). My bet is that you can generate an entire API _and_ basic CRUD browser UI from a db schema. I've been working on a code gener…

I built something a while ago call bam[0] that basically did that. You specces your application in an xml file and it built out the admin ui, orm code, and db schema. I took a bet on a soon to be dead framework and ultimately didn't have time to continue the project, but it worked pretty well.

That makes sense. I'm hedging against dead technology by keeping the database and code generation parts separate from the templates. This way you can have templates for any languages so long as they speak a shared (HTTP) API specification.
Post reply on HN