[oAlbe]

Do you happen to have any resources for learning more about API design in the way you described it? I'm really interested to learn more.

Your comment was very insightful. I used to think somewhat along those lines when it came to designing an API. My thought was that and endpoint was to represent an action the user could perform, and it was none of their business how that was implemented. But I've recently been enlisted in a project to rewrite a whole API (admittedly not a good one at all) where it was decided to use GraphQL. The rationale was "some of our endpoints return enormous objects. Not all of the data is needed every time the client calls that endpoint. Let's implement a way to let the client only ask for the data it needs". It sounded great, but I'm thinking now it might not be all gold as it was presented to me.

[mohbk]

you can solve underfetching and overfetching in a normal restful API, you can have optional entity relationship fetching on query/params, and also user defined queries.

This might be hard/tiresome when you're hand writing SQL queries but this is where query builders and ORMs really shine.

IMO I wouldn't reach for graphQL unless I have a lot of entities and a lot of nested relationships (or an actual graph), it can get either very tiresome to add or overly complex or tightly couples your DB layer when you have deeper nested relationships

[derangedHorse]

Having the client able to dynamically ask for data from models sounds like a horrible idea to me (if I’m understanding correctly). I once had to work with someone who used the Open Data protocol to make an API with a similar approach and hated it because it felt like query writing was moved from him, the backend engineer at the time, to time the front end engineer. In addition to that, the way he did it could have lead to data we didn’t want exposed to be leaked easily by mistake