> Last time I've looked (just a few months ago), the libraries weren't exactly mature-looking, e.g. prone to n+1 queries issue.

This point seems perfectly concrete.

the n+1 comes from the execution module of the reference implementation if you use the "default/simple" logic. But this is just a reference/general purpose implementation. No one said you can not create smarter resolvers that inspect the AST or even create your own execution module. It's possible :) and it works.

Indeed - but there's very little in the way of good examples on how to do that effectively and in a resilient manner, last time I checked.

I find this strange, because this has been a solved problem with graphql-js for about 18 months now, and provided as a core feature in other implementations such as Sangria in Scala. I've written about this particular problem, calling out solutions that exist in different languages:

https://dev-blog.apollodata.com/optimizing-your-graphql-requ...