News for hackers. Stuff that matters.
Re:Living APIs and the Case for GraphQL by masklinn on Friday June 08, 2018 @05:19PM (#17269787)
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.

Re:Living APIs and the Case for GraphQL by hnaccy on Friday June 08, 2018 @09:18PM (#17270979)
How does the backend ensure complex queries are efficient and that the client can't make a costly query without realizing it?
Re:Living APIs and the Case for GraphQL by masklinn on Saturday June 09, 2018 @07:02AM (#17272437)
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.