Context

The context contains the input for the template. It is passed to the resolver code as the first argument of the request/response functions. What values are present depends on the GraphQL query, whether it is for a request or a response mapping template, and whether it's a pipeline or a unit resolver.

The reference contains an up-to-date list of the available values in the context. Here, we are going to discuss these values briefly.

arguments

The ctx.arguments, or ctx.args for short, contains the arguments for the field being resolved. For example, in this query:

query Query1 {
  user(username: "user1") {
    username
    tickets(after: 1639907490) {
      text
      created
    }
  }
}

The ctx.args contains a username for the Query.user and an after for the User.tickets resolver.

source

The ctx.source contains the result of the parent field and is only defined for nested fields. The source provides a way to pass data down the object hierarchy until only leaf nodes remain.

For example, the query contains two levels of nesting:

query Query1 {
  user(username: "user1") {
    username
    tickets(after: 1639907490) {
      text
      created
    }
  }
}

First, the Query.user resolver will run, where the ctx.source is undefined. Then the User.username runs, where the source is the result of the Query.user. The same happens with User.tickets. Then the Ticket.text and the Ticket.created resolvers run, both getting one object from the result of the User.tickets.

identity

The ctx.identity is shared by all resolvers in the query and it contains information about the caller. This information is essential for access control and personalized responses. For example, you'll need to know who the user is to determine if it has access to an object. Moreover, it is a best practice to provide a getCurrentUser query that provides an entry point for users. And to know who the user is, you can use the information in the ctx.identity.

The structure depends on the authorization provider used. For example, a Cognito User has a sub field that is the identifier of the user. But an IAM user has a userArn that is the ARN of the signed-in user. The ctx.identity always reflects the authorization method used for the call if multiple are configured.

AppSync provides a convenience function to decide the authorization type so you don't need to inspect the structure: the util.authType(). This returns a unique string:

Returns a String describing the multi-auth type being used by a request, returning back either "IAM Authorization", "User Pool Authorization", "Open ID Connect Authorization", or "API Key Authorization".

Let's see some examples for different authorization types!

Cognito User Pool

Here, the util.authType() is User Pool Authorization.

And the ctx.identity looks like this: