As for your question, why the user can't change the query (in this example) : because it violates the specifiction and will be rejected by the server.
Does it answer your questions?
What's the point of GraphQL in this case?
> https://news.ycombinator.com/item?id=25432655
In particular:
> Its much harder to make an efficient resolver than it is making an efficient REST endpoint.
As I showed, the claim is not true because it can be solved in the same way in both GraphQL and REST.
I've read the thread. And no, the context wasn't lost.
The whole point of GraphQL is flexible queries. And it is harder to make an efficient resolver in GraphQL than it is in REST.
And yes, your solution (and the solution everyone ends up arriving at) is reimplementing REST in GraphQL, poorly. Precisely because it is much harder to make an efficient resolver in GraphQL.
What is "author" in that query and why can't the user do
in that query?And what you're basically saying is: let's create REST with extra steps for no particular reason. With extremely complex setups where author in one query has a different set of fields than in a different query etc.