Oh and to add my two cents to the discussion about Supabase with or without an API layer (or at least our personal experience and choices).
Indeed for complex (very complex I’d say ) use cases you can certainly take advantage of an API Layer (I feel like clarity of code and maintenance is a big part of the need there)
At Latitudes we have a quite particular use case as we are a NGO with no real tech team (or at least without dedicated developers). We’ve chosen (or at least we’re tending towards) an architecture with only supabase + weweb because it allows us to put a very clear limit between “high code” and “low / no code”.
This way we also have clear roles :
people who are allowed to edit Supabase (and especially security related issues with RLS), a very little number of employees and volunteers who have the technical legitimacy and experience to do that
people who are only allowed to edit WeWeb (hence my concern about their free access to the service_role key ) who are not as technical and may break things but “not that badly”
I feel like the intermediate API layer would have pretty unclear ownership, if you exclude non tech people they won’t be autonomous, if you include them you add security issues / danger to data integrity.
But that’s mostly based on our experience and needs
Back in 2024, there was a discussion about the security concerns regarding the service_role key, and it seemed like steps were being taken to make its use optional. However, I’ve noticed that WeWeb now requires the service_role key again. Could someone please clarify what has changed since then and what measures are currently in place to secure this key?
Hi, due to recent supabase update, we’re now forced to ask you for the service_role key again because it’s not possible to fetch the project schema using the public/anon key anymore.
As we are forced now to enter service role key, i want to ask very simple questions:
Why people that have self-hosted supabase are forced to do it?
We have hosted on our server. Also probably dont have latest supabase version in case this new rule is implemented on self-host, and for example we dont need it on front end.
I think simple switch for self host on-off will do the job for us.
Also about ability to fetch project schema for self-host:
Why not, instead of select element that list tables and columns, to be input field where we write table name, and another to write columns that we want? In that way no need of fetching whole schema.
And no mater that has past 2 years to say something about Hybrid scenario that RobBroberto explained.
I can say that i agree with him. I am using that way and probably i would like to totally move to just calling Postgres/Edge function from Front End. That way:
you are minimizing request complexity on Front end
Edge/Postgres functions have service role access on backend, you dont need to enter it on frontend.
You can filter by user in Postgres/Edge functions so no security problem.
As self-host i was anyway forced to use Rest API request to call Edge function on my backend because with supabase plugin for Edge function you dont have option to manually enter function name, because it is select element, not input field, and for self host, Edge functions are not shown as list in select element for Invoke an Edge Function action in workflow.
I am not so deep in all this but i dont see extra layer here. Or maybe i am missing something.
) use cases you can certainly take advantage of an API Layer (I feel like clarity of code and maintenance is a big part of the need there)
