blog/supabase-alternative

[giscus[bot]]

blog/supabase-alternative

Show the limitation of Supabase RLS(Row Level Security) with a multi-tenancy SaaS example and introduce ZenStack as an alternative.

https://zenstack.dev/blog/supabase-alternative

[eraoul]

Question: would it ever make sense to use both ZenStack and RLS? E.g. for an extra layer of security.

I imagine that anyone building a DB to store sensitive, private user data needs guarantees on who can access the data, and it would be optimal to enforce this both in the backend and in the DB itself.

[jiashengguo]

I agree that’s a reasonable consideration. In fact, we have an FR in Github to support generating RLS from ZenStack’s access policy. You are welcome to join the discussion:
[Feature Request] Generate supabase RLS policies on migration based on Zmodel

[eraoul]

thanks! I've added a comment on that thread. Would be awesome to have auto-generated RLS policies for sure.

[kiptoomm]

Thank you for the article. Is it possible to get the auto-generated Supabase API to respect access control policies defined in Zenstack? I chose Supabase because of the generated API (building boilerplate CRUD endpoints is boring), but I don't like the RLS approach for implementing authz for the maintability/portability reasons you mentioned. The FR discussed in zenstackhq/zenstack#717 would be helpful for sure, but don't know how soon it could be implemented...

[jiashengguo]

Thanks. If you use ZenStack, it also auto generate CRUD APIs for you, either RESTful or RPC styles. It even generate the frontend hooks that you can direclty use in the frontend.

[kiptoomm]

Yes I understand Zenstack creates a RESTful CRUD API around the enhanced Prisma client. However, I'm asking specifically about the REST API that is automatically generated by Supabase via PostgREST. I'm using Supabase and integrated my Refine project with it already, I was hoping that there's a way to "intercept" such API queries and ensure the ZModel rules are enforced. Indeed, I have looked at https://zenstack.dev/blog/refine-dev-backend, but the data provider shown there is manually constructed in src/providers/data-provider/index.ts, whereas with the Refine+Supabase integration, we can use the Supabase-generated API out of the box