Because it solves all sorts of other problems, like having a well-defined way to specify the schema of queries and results, and lots of tools built around that.

I would be surprised to see many (or any) GQL endpoints in systems with significant complexity and scale that allow completely arbitrary requests.

Shopify's GraphQL API limits you in complexity (essentially max number of fields returned), but it's basically arbitrary shapes.

OpenAPI does the same thing for http requests, with tooling around it.

With typed languages you can auto-generate OpenAPI schemas from your code.

Yep, OpenAPI is also a good choice nowadays. That’s typically used with the assumption you’ve chosen a supported subset of queries. With GQL you have to add that on top.

Probably for one of the reasons graphql was created in the first place - accomplish a set of fairly complex operations using one rather than a multitude of API calls. The set can be "everything" or it can be "this well-defined subset".

You could be right, but that's really just "Our API makes multiple calls to itself in the background"

I could be wrong but I thought GraphQL's point of difference from a blind proxy was that it was flexible.

It is flexible, but you don’t have to let it be infinitely flexible. There’s no practical use case for that. (Well, until LLMs, perhaps!)

I guess that I'm reading your initial post a little more strictly than you're meaning

I think they mean something like (or what I think of as) “RPC calls, but with the flexibility to select a granular subset of the result based on one or more schemas”. This is how I’ve used graphql in the past at least.

> I am wondering why you're using graphql if you are kneecapping it and restricting it to set queries.

Because you never want to expose unbounded unlimited dynamic queries in production. You do want a very small subset that you can monitor, debug, and optimize.