Access to GraphQL Query at VTL Resolver Layer

[oxbits]

2 PART FEATURE REQUEST:

1. $context.original_raw_graphql_query_string

   • original raw graphql query/mutation/subscription string
     

2. $context.parsed_graphql_query_json

   • entire graphql query/mutation/subscription parsed into json
     

* at the VTL resolver layer

WHY?:

A. We only get $context.arguments from the client graphql query/mutation/subscription at the VTL resolver layer. There is no way to access the selection set or the original raw query/mutation/subscription.

B. Lambdas could use the selection set information to provide only what the client is asking for. Could save resources on arguments that are expensive to provide.

C. One could simply pass the raw graphql query/mutation/subscription to another graphql endpoint, per schema stitching, schema delegation.

Right now it seems that AppSync basically acts as a filter, expecting the client query selection set at minimum, and dropping any additional data passed back the response mapping template layer.

With the above requested context parameters developers could do so much more with AppSync. Maybe we should even consider including access to the entire incoming http request?

Thoughts?

[mikeparisstuff]

Thoughts:

Providing the selection set at the resolver level is in the backlog but does not yet have a definite date. We have also considered the schema delegation use case and have a backlog item but maybe we can do more with less than initially thought.

Can you provide a few more details as to what you were thinking? AppSync won't automatically introspect downstream APIs for you so to proxy a query directly to a downstream API you would likely need to mirror the aspects of the schema in AppSync so the passed query would validate both the AppSync schema as well as your own. Is this your plan? If we gave access to the query via $ctx.query then you could accomplish this with HTTP resolvers. There are few details overlooked here such as what if the requests "query" is actually a set of operations instead of a single query. In this case would $ctx.query be the full document or should it be the single operation being invoked? If it is the full query then we would need to provide the operation name as well.

As for the full HTTP request, what information do you need that you do not have outside of the query/selection set? You have access to headers and any relevant input values via arguments.

[oxbits]

I am happy to hear all-a-y'all are thinking about these items and working to determine the right ways to access them from the VTL resolver layer. You are definitely diving into it deeper than I had considered, which is also awesome.

I simply thought that we should have as much information at the VTL resolver layer as possible. Then we don't have to do silly hacks like passing the information we want through AppSync parameters you currently provide access to. The idea of taking the raw query/mutation/subscription and simply handing it off to another graphql endpoint seemed like an interesting idea. I have never done it, was going to try it, and then ran into this limitation in AppSync.

While I am still learning all the intricacies of these technologies, I would simply request that you and your team hedge on the side of providing as much transparency at the VTL resolver layer as possible about anything and everything that is know about the current query/mutation/subscription, request, context, auth, etc. (much is already available). Given the raw materials, the community may come up with use cases you had not considered.

Thank you for your consideration and thank you for the awesome services/tools. Come visit the AWS Loft in NYC some time!

[solussd]

I would like to second this request– having access to the GraphQL query would allow optimized data resolution. In my case, I use a lambda to access data in a Datomic database. Datomic has "pull" queries, which map nicely to GraphQL queries. It'd allow me to resolve several nested objects in a single resolver, rather than executing several resolvers and having them composed in Appsync, itself.

[SwaySway]

Closing this seems like a dependency issue. AppSync has the $context.info object which can provide the selection set and more information. Docs: https://aws.amazon.com/blogs/mobile/appsync-and-the-graphql-info-object/

{
    "fieldName": "string",
    "parentTypeName": "string",
    "variables": { ... },
    "selectionSetList": ["string"],
    "selectionSetGraphQL": "string"
}

[github-actions[bot]]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.