grpc is a bog-standard "shallow" RPC: client calls an endpoint, client gets a result, if client needs sub-results it calls more endpoints.

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.

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.

Good question!

I'm guessing typical implementations would involve a lot of caching.

It would be nice to hear about people's experiences though.

gRPC makes it easy to talk to a server with flat input/output types like in a function call. GraphQL is more a query language.

In some ways, analogous to your client using SQL instead of an ORM to query a system.