4 ms·

Supabase is the iPhone to Firebase's Palm V -- highly recommend, if you're a fellow millenial like me who grew up on mobile, and things like "much less code to

Supabase is the iPhone to Firebase's Palm V -- highly recommend, if you're a fellow millenial like me who grew up on mobile, and things like "much less code to just write a simple API backend for your thing" sounds like 6 months and paying another engineer. EDIT: loud buzzer Careful, Icarus: "permissions can be setup to allow global read-writes" is a "vuln" of every system. p.s. Any comment on why her blog has you guys "remembering Chattr" then getting a seedy Firebase pwner GUI, and yours has you diligently looking through .ai TLDs?

zilti 3y ago
At that point, you might as well just use PostgREST.
MrBruh 3y ago
loud buzzer Sorry, but supabase has a similar issue. Another blog going over that has or will be made by Eva (referenced on the site)
- dazh 3y ago
  Would be very interested in reading about SB. Has it already been posted?
rezonant 3y ago
> sounds like 6 months and paying another engineer. If you take this approach, it's "pay now or pay later". -- Fellow millenial
n2d4 3y ago
I think Supabase is much better than Firebase, but I find its security model worse; Firebase was very clearly designed with this in mind, while Supabase is just a Postgres DB with RLS as an afterthought. One particular thing that annoys me with SB is that by default, or when you create a table with SQL, they're publicly accessible, which is very bad! (Firebase defaults to no access in production mode.)
- anoncareer0212 3y ago
  In what way do you perceive it to be an after thought? It's front-and-center constantly, and has _all_ access disabled by default on tables every time I use it.
  - n2d4 3y ago
    It only has access disabled if you enable RLS on that table. If you do `CREATE TABLE`, or don't check the checkbox in the UI (TBF it's big and green and has a warning that's hard to miss), then access is public. I guess my main concern is that it's hard to setup RLS correctly using SQL. Because it's two separate statements, if your `CREATE TABLE` succeeds, but the `CREATE POLICY` does not, you're also exposed. And it is more annoying than it should've been to test the rules (Firebase has a dedicated tool for that). I now just use Supabase to host a normal Postgres that only my backend connects to. That works well.
    - bravura 3y ago
      I built a supabase app the past two days, and I agree. I did find it a footgun that creating a table through SQL was not private by default. (Why doesn't Supabase apply RLS by default to tables created through SQL?) Serverless also turned out to be more trouble than it was worth. In particular: * Doing DB business logic in JS is gross. * It's tricky to secure a table to be semi-public. e.g. you have a bookmark site and you don't want users to browse all URLs, just the ones they have bookmarked. The best solution appears to be disabling foreign-keys until transactions are done and then having a complicated policy. * It's a pain to set up a CLI client that interacts with the DB. I think you have to copy-paste the access AND refresh tokens to it. I couldn't figure out a way to create my own API tokens. A backend is nice, because it is private by default.
- Sai_ 3y ago
  Don’t believe tables are readable by default even if you have defined any RLS policies for that table. I’m building something on SB right now and have been burned more than once because I thought that the absence of policy meant open access to everyone.
hot_gril 3y ago
> "permissions can be setup to allow global read-writes" is a "vuln" of every system Question is how much effort that is. It's scarily easy on Firebase, idk about Supabase.
codesnik 3y ago
Used it and can't actually recommend it. RLS policies slows down even simplest queries 1000x times sometimes, and postgres' current EXPLAIN ANALYZE isn't helping much. Testing app on it is still a pain. Default migration engine is oneway. Backed in database backups are close to useless. I mean, I managed to solve a lot of those issues for myself, but it still felt like I'm reinventing bicycles instead of doing actual work, and I still had a subpar experience.
quickthrower2 3y ago
I'll happily take 6 months pay to knock up a quick node api. :-). Just need to find a beach first. What I found is you are right and FB is easier for the Millennial, Gen Z, Boomer or whatever IF everything you need can be done by rules and schema. As soon as you need to write functions (because rules are not sophisticated enough or too slow/expensive, or you want to know why the thing got denied) then you are writing backend code. It is actually easier to write the same code in a NextJS template - like there is less to learn, less docs to read. And then chuck it on Vercel which will deploy and devops it for you. So you have all the devops done for you like Firebase would and you have spent less time. Now if you are talking to postgres instead of firebase from the backend, it is actually easier IMO. A line to connect to pg. A line to issue a query. Guess this is just my opinion, but it is less code to do so, less environment variable farting around, downloading a weird .json with all the credentials. If I were inclined I would write a blog post showing how much less lines of code are needed, how much less understanding is needed, and with the managed infra/DB offered by Vercel etc. you are still serverless, etc.

zilti 3y ago

At that point, you might as well just use PostgREST.

MrBruh 3y ago

loud buzzer Sorry, but supabase has a similar issue. Another blog going over that has or will be made by Eva (referenced on the site)

dazh 3y ago
Would be very interested in reading about SB. Has it already been posted?

rezonant 3y ago

> sounds like 6 months and paying another engineer. If you take this approach, it's "pay now or pay later". -- Fellow millenial

n2d4 3y ago

I think Supabase is much better than Firebase, but I find its security model worse; Firebase was very clearly designed with this in mind, while Supabase is just a Postgres DB with RLS as an afterthought. One particular thing that annoys me with SB is that by default, or when you create a table with SQL, they're publicly accessible, which is very bad! (Firebase defaults to no access in production mode.)

anoncareer0212 3y ago
In what way do you perceive it to be an after thought? It's front-and-center constantly, and has _all_ access disabled by default on tables every time I use it.
- n2d4 3y ago
  It only has access disabled if you enable RLS on that table. If you do `CREATE TABLE`, or don't check the checkbox in the UI (TBF it's big and green and has a warning that's hard to miss), then access is public. I guess my main concern is that it's hard to setup RLS correctly using SQL. Because it's two separate statements, if your `CREATE TABLE` succeeds, but the `CREATE POLICY` does not, you're also exposed. And it is more annoying than it should've been to test the rules (Firebase has a dedicated tool for that). I now just use Supabase to host a normal Postgres that only my backend connects to. That works well.
  - bravura 3y ago
    I built a supabase app the past two days, and I agree. I did find it a footgun that creating a table through SQL was not private by default. (Why doesn't Supabase apply RLS by default to tables created through SQL?) Serverless also turned out to be more trouble than it was worth. In particular: * Doing DB business logic in JS is gross. * It's tricky to secure a table to be semi-public. e.g. you have a bookmark site and you don't want users to browse all URLs, just the ones they have bookmarked. The best solution appears to be disabling foreign-keys until transactions are done and then having a complicated policy. * It's a pain to set up a CLI client that interacts with the DB. I think you have to copy-paste the access AND refresh tokens to it. I couldn't figure out a way to create my own API tokens. A backend is nice, because it is private by default.
Sai_ 3y ago
Don’t believe tables are readable by default even if you have defined any RLS policies for that table. I’m building something on SB right now and have been burned more than once because I thought that the absence of policy meant open access to everyone.

hot_gril 3y ago

> "permissions can be setup to allow global read-writes" is a "vuln" of every system Question is how much effort that is. It's scarily easy on Firebase, idk about Supabase.

codesnik 3y ago

Used it and can't actually recommend it. RLS policies slows down even simplest queries 1000x times sometimes, and postgres' current EXPLAIN ANALYZE isn't helping much. Testing app on it is still a pain. Default migration engine is oneway. Backed in database backups are close to useless. I mean, I managed to solve a lot of those issues for myself, but it still felt like I'm reinventing bicycles instead of doing actual work, and I still had a subpar experience.

quickthrower2 3y ago

I'll happily take 6 months pay to knock up a quick node api. :-). Just need to find a beach first. What I found is you are right and FB is easier for the Millennial, Gen Z, Boomer or whatever IF everything you need can be done by rules and schema. As soon as you need to write functions (because rules are not sophisticated enough or too slow/expensive, or you want to know why the thing got denied) then you are writing backend code. It is actually easier to write the same code in a NextJS template - like there is less to learn, less docs to read. And then chuck it on Vercel which will deploy and devops it for you. So you have all the devops done for you like Firebase would and you have spent less time. Now if you are talking to postgres instead of firebase from the backend, it is actually easier IMO. A line to connect to pg. A line to issue a query. Guess this is just my opinion, but it is less code to do so, less environment variable farting around, downloading a weird .json with all the credentials. If I were inclined I would write a blog post showing how much less lines of code are needed, how much less understanding is needed, and with the managed infra/DB offered by Vercel etc. you are still serverless, etc.