If you're a backend dev that makes APIs, you probably won't like GraphQL (I am not one of those, BTW). If you have a big project with a team split into API dev

If you're a backend dev that makes APIs, you probably won't like GraphQL (I am not one of those, BTW). If you have a big project with a team split into API devs and app devs, and you have to wait, then that is poor planing. Plus, just wait, jeez. Don't blame the separation of the work into roles for your problems, it is usually good, and often necessary. Then again, if you're full-stack developer, you can just go fix the endpoint yourself. I know the argument about over-fetching with an API is that you have to make one call, than loop through and make secondary calls, but you can mitigate that, it is rare, and is actually fine. Ad-hoc data modeling encourages over-fetching in it's own way. You always make in-situ calls for exactly the model shape you need right there. "That model is not quite the shape I want, I will do another query." Plus, with pre-defined data models you can save them, in like a state object, they are more reusable. You can even use them in a totally different program.