GraphQL scares people because it seems to to allow arbitrary complex queries from applications. But that complexity was always there. REST just hides it in an unbounded number of predictable HTTP requests.
The same computatational challenges we've always had with mapping relational models to REST didn't go away, mainly: N+1 queries, recursive types and query parameters adding complexity.
With exceptions:
Preventing endless recursion: Or else it'd be possible for a client to timeout with queries [1]. In graphene recursion can be checked via `info.path`.
Calculated / slow fields: Makes more sense to have dedicated objects if calculations are involved, so if they're lists/connections, there can be limits imposed for how many can be grabbed at a time.
Sometimes the only way to be sure is to only allow access to these objects if they're a direct ID lookup at the root, e.g:
repos(id: <ID>) -> stats -> TotalLikesForAllIssues.
Assume that if cold and uncached, it could take <1s to calculate that. Imagine if we were to have that ran multiple times:
User -> repos(first: 20) -> stats -> TotalLikesForAllIssues.
So in my case I want to make the data available, but it's not always a direct mapping to SQL. And I'm also making rules inside where the client is limited in how, and how much they can query.
[1] Further reading: http://facebook.github.io/graphql/#sec-Fragment-spreads-must..., https://github.com/graphql/graphql-spec/issues/91