It wasn’t that long ago that I was listening to an Indie Hackers podcast about Supabase. Supabase is an open-source Firebase alternative and so far we are absolutely loving using it for our current project. The experience has been great.
I have begun to model data in it and one of the things that I love is that you get instant API’s spun up to access that data. Supabase, knowing that many of today’s applications are client-only and not really dealing in backend code went ahead and created a really useful feature in their product.
Row level security has been bomb too, allowing you to specify down to absurdly specific detail row-level access to the database. And since it’s just a Postgres database under the hood it’s all in SQL!
Check out something that I just did recently - granted I am just starting to mess around with the project
CREATE POLICY "policy_name"
ON public.todos
FOR UPDATE USING (
auth.uid() = owner
) WITH CHECK (
auth.uid() = owner
);
Auth and uid() are stored and exposed via Supabase and Supabase’s native functionality. You get that table for free if you turn on authentication. Now you can use that in these security policies, applied to rows, that allow you to
segment access to specific users. The above checks to see if the caller (whoever is logged in) happens to be the owner of a specific row in the database. I find this to be absurdly powerful (and more proficient) than Firebase security
policies because in Firebase you are stuck with their specific query language. Anything that matches what develoeprs already know and can reason about is a huge win in my book.
One thing that is worth mentioning is how service roles work. Our specific need is to have a Supabase client on the backend. This is possible through what in Firebase is known as the Admin SDK. There is no such distinction in Supabase, you instead
must use your service key which is readily present on the front page of your dashboard. This is great because there is no confusion, but not so great for security purposes to have one unlock all key that bypasses all of the RLS policy. We
may have to write some kind of code to rotate the service key to be safe, but that is the least of our concerns in MVP stage
Expect more posts like this and learnings from using Supabase. I am a very happy customer at the moment. We are integrating it into a Python backend and with the pricing model it is hard not to get excited! Soon we will have a need for edge functions too and that means more fun (and Typescript) as time goes on.