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 