How to Manage Custom API Routes for Different User Roles?

[pourya7]

TL;DR: How can I manage custom API routes in Supabase, ensuring flexibility for different user roles without exposing auto-generated endpoints?

Hi Supabase Community,

I’m considering using Supabase for an API-first backend and am facing challenges with managing custom API routes tailored to different user roles. The core issue is how to effectively segregate API routes for different types of users (admins, authenticated users, anonymous users) while maintaining flexibility and clean route structures.

Example Scenario:

Let’s say I’m building an education system with a lessons table. I want to expose the lessons data through different API routes depending on the user’s role:

1. Admin Panel: Admins should manage lessons through domain.com/api/v1/cms/lessons, with full CRUD capabilities.
2. Anonymous Users: Unauthenticated users should only access lesson titles via domain.com/api/v1/lessons.
3. Authenticated Users: Logged-in users should access detailed lesson information via domain.com/api/v1/my/lessons.

What I've Considered:

To prevent exposing auto-generated endpoints for tables, views, and functions, I’m using the PostgREST schema isolation strategy to separate my public schema from my api schema. This allows me to isolate the tables from being directly exposed. However, even with this approach, views and functions still get exposed with less-than-ideal route naming conventions such as domain.com/rest/v1/admin_lessons or domain.com/rpc/add_lesson.

I’ve looked into using API gateways to manage custom routing and enhance security. However, using an API gateway adds a layer of complexity, making the product less maintainable. It requires constantly keeping track of the endpoints exposed by PostgREST and ensuring they align with the custom routes defined on the API gateway side.

I’m wondering if using an API gateway is the only path forward or if there are other best practices within Supabase to achieve clean, well-structured API routes tailored to different user roles.

Thanks for your insights!

[bytaesu]

Here’s a link that might help answer your question: Supabase Docs > Hardening the Data API

I believe combining Edge Functions, Row-Level Security (RLS), and the insights from this guide can significantly improve your security setup.

If you have any further questions, I’d be happy to answer them, even though my knowledge may not be perfect. I’m continually learning as I help others.

[pourya7]

Thank you @bytaesu for the help

I have already considered the two options suggested under: Supabase Docs > Hardening the Data API

1. To disable Data API entirely, means to disable PostgREST and building a custom back-end layer on top of the PostgreSQL database, which goes against the whole purpose of using Supabase in the first place.
2. To create separate schemas and only expose api schema, which is the same as what is suggested in the PostgREST schema isolation strategy.

Though the main issue still remains! To make API-first services using Supabase, it is either using a paid service such as Zuplo or configuring an API gateway.

Here I'm just wondering if there is any other way, to avoid API setups in multiple places.

[bytaesu]

Are you concerned about API naming for an intuitive API structure?

If you use Next.js, you can design your APIs using Route handlers (API routes) and call Supabase clients on those endpoints.

Or, you can use Supabase edge functions.

Did I understand your problem correctly?