Is there a way to access the query AST within a resolver?

[swatkatz]

Hi,

When graphql_sync or graphql gets called, ariadne uses the parser from graphql-core to parse the query. I want to access this query document in my resolver for transforming part of the query to an existing system in order to execute the logic in that resolver.

Is there a way to access this document using info or the execution context within the resolver? If not, what would be the recommended approach of providing this information to the resolver? I am trying to avoid parsing the query twice and storing the parsed query in "my context".

[Namrata766]

Did you find any solution to this problem?

[rafalp]

transforming part of the query to an existing system in order to execute the logic in that resolver

This isn't going to work. By the time resolver is hit, query executor has already created resolver graph and is walking it (not query AST). Fragment of this graph containing current node and child nodes is available via info.field_nodes.

@swatkatz @Namrata766 Can you provide more detailed example of what problem you are trying to solve? From your description it sounds like what you are trying to do is VERY BAD and there's gotta be better way.

[swatkatz]

My use-case doesn't involve changing the resolver execution, but I need the query AST for building some metadata information that would help fetch the data in the resolver. Anyway, my "solution" was to rewrite the graphql_sync method bypassing Ariadne's wrapper and using the graphql-core functions directly which gave me access to the document_node which I then include as part of the context that is set on info, so something like

info.context.document_node = parse(query)

I think in most vanilla graphql implementations, we probably don't need access to the document_node, but re-writing the wrapper might give some performance benefits as described below.

This had the added benefit of skipping query validations for better performance as we have query safelisting and don't need to validate the query during runtime if we've already registered it + adding the query document to a local cache so that we don't have to keep parsing it each time.