[whstl]

With Supabase or Hasura you would write the same client code you would write if you were using a traditional backend.

At least when used correctly, but honestly I can’t see a situation where it’s easy to do otherwise for queries.

The utility is in not having to write a lot of repetitive endpoints in a traditional backend, for a large amount of endpoints.

What exactly do you mean by “query logic in the client code”?

[DidYaWipe]

I mean instead of doing a GET on an endpoint called userMessages with an ID parameter, you're formulating a join in the client between specific tables.

[whstl]

That's not necessarily true.

In PostgREST, if userMessages is a table in itself, you do get an endpoint called /userMessages.

If the table is called messages and you want to get messages from a user, you can just request something like /messages?user_id=123. And if user_id must your own user_id, you can just skip passing the parameter, thanks to RLS.

If userMessages requires is a join between two tables and you don't want to let the frontend know about it, you can use a view and PostgREST will expose the view as an endpoint.

Once again, there is no "need" to formulate joins in the frontend to reap the benefits of this tool.

I don't do anything close to "formulating a join in the client" with PostgREST and I still use it to its full extent, and it does save time.

EDIT: If one wants to formulate more complex joins in the frontend, then they probably want something like Hasura instead. Once again: complex queries in the frontend is BY NO MEANS mandatory, you can still use flat GraphQL queries and db views for complex queries. PostgREST OTOH is about keeping it simple.

[DidYaWipe]

Thanks for the reply. If your database is normalized to any degree and you have multi-way relationships, I don't really see significant payoff from the auto-generated API vs. writing traditional queries and endpoints.