> it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically.
Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?
> Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?
You could write such a wrapper, but it won't be standard, which means that there will never be a robust library ecosystem and set of practices that arises from that. If GraphQL was to evolve, you also wouldn't be sure your wrapper can express all of GraphQL. Finally, this would add new practical hurdles, like a new dependency, additional runtime cost of compilation, obscured source mapping, etc.
Meanwhile, because GraphQL is just a text-based DSL, most people don't have a clear idea of the _information model_ of GraphQL queries - you have to read the spec to get this idea. If we are to build a robust ecosystem on top of GraphQL, this information model should be evident in the API.
All these problems are present, and very damaging, in SQL.
Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?