[whstl]

I never said anything of the sort, what are you talking about?

[DidYaWipe]

"...an automatic CRUD API. And I don't see what's the dilemma here. Just use a normal endpoint. Keep using PostgREST to save time."

[whstl]

Where in my message does it say or imply that you should “hard code queries in your client application?”?

EDIT: What I’m advocating here is the opposite: use those tools for CRUD so that your frontend looks exactly the same as a frontend with a regular backend would. If the tool is not good for it (like the example), just use a regular endpoint in whatever backend language or framework. Don’t throw the baby (the 95%) with the bathwater (the 5%).

By “just use a normal endpoint” I mean “write a normal backend for the necessary cases”.

[DidYaWipe]

Of what use is an "automatic CRUD API" if you're not putting query logic in your client application?

[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.