4 ms·

"...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 1y ago
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 1y ago
  Of what use is an "automatic CRUD API" if you're not putting query logic in your client application?
  - whstl 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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.

whstl 1y ago

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 1y ago
Of what use is an "automatic CRUD API" if you're not putting query logic in your client application?
- whstl 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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.