This is a bit off-topic, but I would really like to see a good query optimiser for GraphQL. Last I checked the industry standard solution to the "N+1 selects" p

This is a bit off-topic, but I would really like to see a good query optimiser for GraphQL. Last I checked the industry standard solution to the "N+1 selects" problem that nested queries trigger was to add a delay and attempt to batch those N calls into one. I expect EdgeDB's GraphQL implementation just translates to EdgeQL/SQL and can simply optimise that. (Probably Hasura does this too.) But I have yet to see anything near that in a GraphQL server implementation for any programming language. From the GraphQL FAQ: > Accessing and manipulating data is performed with arbitrary functions called resolvers. ... Generally, these resolver functions should delegate to a business logic layer responsible for communicating with the various underlying data sources. These data sources could be remote APIs, databases, local cache, and nearly anything else your programming language can access. Somehow the lets-implement-this-syntax-in-100-popular-languages part of being a new language means these GraphQL server libraries just give you bare bones "get by id", "get all" interfaces to implement, and you're stuck with their dumb processing. This looks like a pretty standard experience of implementing GraphQL, and having to clear out a dozen jaw-droppingly dumb bugs introduced because the libraries do literally nothing for you: https://www.toptal.com/graphql/graphql-internal-api-optimization https://www.toptal.com/graphql/graphql-internal-api-optimiza.... Being a language, of course it must describe what the queries actually do in abstract, naive terms. Just like a programming language standard. But undefined behaviours are meant to be exploited, not used as a prototype for every implementation on Earth. I don't think GraphQL implementations are doing this nearly enough, considering that the goal is to build an SQL-like for arbitrary data backends. SQL databases ALL have optimisers. It's simply non-negotiable. For GraphQL, do whatever you need -- ask me which collections are available as tables in the same database so you can reorganise a query and send them as one "codegen unit", ask me to estimate the cost of using a resolver, ask me to build and keep indexes. That's the job, right?