CODEWITHSUNDEEP
amazon-web-servicesaws-lambdagraphqlaws-appsync
Mihai Blaga
Mihai Blaga

Reputation: 121

AWS AppSync Lambda resolver fields

I have the following query:

query xxx {
   getSomething(id: "id") {
      field1
      field2
   }
}

Is there any way for me to get field1 and field2 in lambda? For example, to query only those fields in mysql, not get all of them just to be discarded by AppSync later.

I tried logging all the $context in the request mapper VTL file but they are not there. Any ideas? Seems quite stupid to not be able to do that. The only thing I get in lambda is the id argument.

Thanks, Mihai

Upvotes: 8

Views: 2857

Answers (3)

Trisped
Trisped

Reputation: 6003

AppSync now supports getting the GraphQL Info object. You can get the list of requested columns from the selectionSetList variable.

The layout of the Info object:

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

An example passing the selectionSetList property to a lambda resolver:

{
    "version" : "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "arguments": $utils.toJson($ctx.args),
        "selectionSetList": $utils.toJson($ctx.info.selectionSetList),
        "selectionSetGraphQL": $utils.toJson($ctx.info.selectionSetGraphQL)
    }
}

Note: If you are trying to pass the selectionSetList then you need to specifically reference it (like in the example above). The list will not be available if the info object is passed in directly with something like $utils.toJson($ctx.info).

Upvotes: 6

bwobst
bwobst

Reputation: 351

Those fields are in the $context.source object. If you pass the entire $context object to your lambda you'd be able to access those fields in event.source

Upvotes: 0

thomasmichaelwallace
thomasmichaelwallace

Reputation: 8464

It might not be the answer you want to hear, but as you've spotted AppSync simply doesn't make the graphql (fields, or otherwise) available to you.

The only two 'options" I can put to you are:

  • Design your query schema so that you can be more precise with your fetching (e.g. getThingFromTableA and getThingFromTableB rather than just getThing)
  • Use field resolvers for expensive to get fields, and employ nested objects if these are all from the same datasource (e.g. { cheapA, cheapB, expensiveA { expensiveTableAThingA, expensiveTableAThingB }, expensiveB }).

n.b. it isn't that uncommon, for example Apollo doesn't by default either.

Upvotes: 4

Related Questions