I love the idea of GraphQL and Apollo, but there are two things that I am not sure about.
Jeff Whelpley

This is not a direct answer but more of a collection of thought that hopefully can give you a bit of insight into the whole topic.

Consider this nested query that asks for the text of all comments made by all friends of a specific user:

allUsers(id: "user-id") {
friends {
comments {

Given these data requirements, the server actually has the chance to optimize the query to sent to the data layer. In this case, theorethically, we could satisfy the data requirements by a single deeply nested SQL query, that joins over all the different tables and filters by the resulting comments accordingly. This would probably result in a good enough performance for most use cases.

Granted; even though this is a small example, it’s already quite complex to be handled in a satisfactory way for all possible cases. The GraphQL community will probably need some time to figure out best practices and develop different approaches for these kind of problems. But by having the full knowledge of data requirements, we can start to think on these problems in the first place.

One critical benefit of using GraphQL in this context is that the GraphQL schema and the actual database schema are decoupled: even if the above GraphQL query suggests a certain schema on the database, we could choose a completely arbitrary one. We only have to be able to fulfill all the possible queries and somehow map the GraphQL schema to the database schema. For REST, we kind of have an implicit schema somewhere, but we have to follow it explicitely on the client and on the server on the network layer.

The GraphQL community still has a lot of best practices to figure out and a lot of approaches to even experiment. Maybe some of the answers will be similar to how REST backends solves certain issues (for example data denormalisation on the data layer), but with GraphQL there are a lot of possible directions of research that will take some time to be fully understood and simply do not exist with REST.