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