For restricting queries, an option is using persisted queries (e.g. https://dev-blog.apollodata.com/persisted-graphql-queries-wi...).
The idea is nice, having full control in development while locking down allowed queries in production.
You'd still have to deal with the problems you mentioned in development, some of which are indeed a little ugly (at least currently).
However, I totally understand the confusion in my sentence and actually this thing you're talking about is also useful to me :)
Haxl seems particularly suited for this (I think it's the same thing as Dataloader, both from facebook?) as it can efficiently batch and cache queries to multiple sources at the same time. It seems like a good layer between GraphQL and your N data sources.
And comparing to something like Django/Rails - there's a lot more DIY involved.
The ugliest part of it, or one requiring most hacky solutions, is optimising queries. For example, there are some nasty N+1 traps or "oops-I-joined-your-entire-database" problems when using SQL.
JoinMonster helps with this, but it is a bit too much of a "full solution" or framework to just quickly use. You'll also lose a lot of control over your queries which was a big reason for me to move from Django/Rails/etc. style tools to trying out GraphQL.
This project seems to avoid databases entirely and it seems to have an N+1 queries problem when fetching comments. Each comment is fetched with a separate API call and a single HN Post can easily have hundreds of comments... even if cached, this is a problem.
The SQL "WHERE IN (list of IDs)" query combined with smart caching and batching (see: Dataloader by Facebook, JoinMonster) is a decent solution but requires some amount of good old manual work.
tldr; GraphQL is nice but has its own set of problems. Still no magic bullets.