How does the backend ensure complex queries are efficient and that the client can't make a costly query without realizing it?
graphql does not provide for more complex queries than a regular RPC, the API designers decides specifically what they want to provide at each level.
What they do is coalesce all those separate queries into one, and actually allow for sub-query optimisations if you feel like it.
So the answer is that it does not, any more than e.g. grpc does not.
Re:Living APIs and the Case for GraphQL
by alter_eco123 on Friday June 08, 2018 @10:03PM
(#17271107)
Good question!
I'm guessing typical implementations would involve a lot of caching.
It would be nice to hear about people's experiences though.
GraphQL queries have depth, when you call a toplevel endpoint which returns a non-trivial type you can select fields of the sub-resources to fetch, in fact you can also select just a slice of the top-level resource as well.
Let's say HN had a grpc API and you wanted the top comment of each article of the main page, unless it provided a very specific endpoint doing that you'd probably have to list the front page (and get a whole host of crap you don't care for e.g. the title, the destination URL, the score, the author, …), and for each article get its comments (again with all sorts of metadata you may not care for). In GraphQL, you'd select all but exactly what you need at once.