I'd argue GraphQL really doesn't even solve that "mini-query-language" problem all that well. But, I'm with you; that's how its sold. Its one of the big things

I'd argue GraphQL really doesn't even solve that "mini-query-language" problem all that well. But, I'm with you; that's how its sold. Its one of the big things its proponents say. And it fails at it. Let me pick on an example of one of these rest-api-mini-query-language specs: the Microsoft Graph API, which uses OData. It supports: * Count (don't return items; return a count of them) * Expand (graph traversal on related resources) * Filter * Format * Order (sorting) * Search * Select * Skip * SkipToken * Top * A bevy of others Of these; GraphQL solves Select and Expand. That's it. Everything else INEVITABLY becomes a pseudo-odata-mini-query-language on top of GraphQL; the exact same problem REST APIs had! Pagination. Skip/limits. Response reducing/counting/analytics. Filtering. Etc. Of course, a framework has to stop somewhere. Lest you become OData, which isn't all that great to use. So, I'm not proposing that GraphQL should do more; but rather that its proponents need to stop listing this as an advantage of the framework, because its actually a disadvantage. Its only "good" at this relative to literally `npm i express`; the most basic-possible-REST-API. The REST & RPC ecosystems have a wide array of higher level tooling to select from, at every possible level of "nothing" to "everything and the kitchen sink"; GraphQL is startlingly boring in comparison, and proponents who list this as an advantage of GraphQL really aren't doing much more than admitting how little exposure they have in competing frameworks (or, similarly, how poorly APIs were built at whatever company they worked at last).