I wonder how schema information/introspection from the back end could be used to improve this further.
Apollo has the codegen tool which uses the schema to automatically generate the required classes.
On a cursory glance, it seems like with this tool, you write a JS object in the same shape as the query, manually specifying the type of each field in that object, and then it generates the query for you to pass to graphql clients, as well as the types associated with the result of that query for you to use in your app. Whereas with Apollo's codegen, you write the query in graphql syntax, then run a CLI command to generate the types associated with that query for you to import and use.
It seems with this tool, you'd still have to manually state the type of each field (when that information can be perfectly inferred from the schema as demonstrated by Apollo's codegen), and you'd lose the ability to take advantage of tools that work with the graphql syntax to provide things like autocomplete based on your graphql schema while you're writing the query itself (https://github.com/apollographql/vscode-graphql, for instance). Unfortunately I'm not yet able see any benefits you'd get over Apollo's codegen in return. Happy to be enlightened if I'm missing anything.
Type information can be perfectly inferred from the schema. I agree though.
Yes, Apollo's schema validation is really awesome as we can find wrong type before we run code. I would like to add feature in the future.
Thank you for your suggestion!