You mean a filter to transform the query from A (say, with syntactic sugar syntax) to B (with final syntax)? I'm actually doing something similar in GraphQL by

You mean a filter to transform the query from A (say, with syntactic sugar syntax) to B (with final syntax)? I'm actually doing something similar in GraphQL by PoP, on a couple of levels: queries are decoupled into requested and executable, where they can differ in syntax, directives attached to them, and others. I wrote a bit about this strategy here: https://blog.logrocket.com/adding-directives-schema-code-first-graphql-servers/ https://blog.logrocket.com/adding-directives-schema-code-fir... In addition, GraphQL by PoP does not understand the GraphQL syntax. It understands another syntax, that I've called PQL: https://graphql-by-pop.com/docs/extended/pql.html https://graphql-by-pop.com/docs/extended/pql.html. PQL is a superset of the GraphQL query, so GraphQL by PoP transforms from GraphQL to PQL syntax and then executes it. For instance, this GraphQL query: ``` query { posts { excerpt titleES: title @translate(from:"en",to:"en") } } ``` is converted to this: ``` posts.excerpt|title@titleES<translate(from:en,to:es)> ``` Check it out here: https://newapi.getpop.org/api/graphql/?query=posts.excerpt|title@titleES%3Ctranslate(from:en,to:es)%3E https://newapi.getpop.org/api/graphql/?query=posts.excerpt|t... This works great. Only issue is when there's some error when retrieving the data, and I need to return an error message with the path to the problem in the query. In that case, the path corresponds to the transformed PQL query, not the original GraphQL query. (It would be possible to have a mapping for them, token by token, but I haven't coded it) --- Btw, connected to PQL, GraphQL by PoP can support the embeddable fields feature because the PQL supports composable fields, which can be considered its superset: https://graphql-by-pop.com/docs/extended/pql-language-features.html#composable-fields https://graphql-by-pop.com/docs/extended/pql-language-featur... I've also proposed composable fields for the GraphQL spec (https://github.com/graphql/graphql-spec/issues/682 https://github.com/graphql/graphql-spec/issues/682) but it hasn't got any support (that's why I'm now asking if embeddable fields could have some backing)