Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS AppSync JavaScript référence à l'objet contextuel du résolveur

AWS AppSync définit un ensemble de variables et de fonctions permettant de travailler avec les gestionnaires de demandes et de réponses. Cela facilite les opérations logiques sur les données avec GraphQL. Ce document décrit ces fonctions et fournit des exemples.

Accès à la variable context

L'contextargument d'un gestionnaire de demandes et de réponses est un objet qui contient toutes les informations contextuelles pour l'invocation de votre résolveur. Elle présente la structure suivante :

type Context = {
  arguments: any;
  args: any;
  identity: Identity;
  source: any;
  error?: {
    message: string;
    type: string;
  };
  stash: any;
  result: any;
  prev: any;
  request: Request;
  info: Info;
};

Chaque champ de l'contextobjet est défini comme suit :

Champs de context

Identity

La section identity contient les informations sur l'appelant. La forme de cette section dépend du type d'autorisation de votre AWS AppSync API.

Pour plus d'informations sur les options AWS AppSync de sécurité, consultez la section Autorisation et authentification.

Chaque champ est défini comme suit :

En-têtes de demande d'accès

AWS AppSync permet de transmettre des en-têtes personnalisés depuis les clients et d'y accéder dans vos résolveurs GraphQL en utilisant. ctx.request.headers Vous pouvez ensuite utiliser les valeurs d'en-tête pour des actions telles que l'insertion de données dans une source de données ou les contrôles d'autorisation. Vous pouvez utiliser un ou plusieurs en-têtes de demande à l'$curlaide d'une API touche depuis la ligne de commande, comme indiqué dans les exemples suivants :

Exemple d'en-tête unique

Supposons que vous définissiez un en-tête custom avec la valeur nadia, comme suit :

curl -XPOST -H "Content-Type:application/graphql" -H "custom:nadia" -H "x-api-key:<API-KEY-VALUE>" -d '{"query":"mutation { createEvent(name: \"demo\", when: \"Next Friday!\", where: \"Here!\") {id name when where description}}"}' https://<ENDPOINT>/graphql

Il est alors possible d'y accéder avec ctx.request.headers.custom. Par exemple, cela peut se trouver dans le code suivant pour DynamoDB :

"custom": util.dynamodb.toDynamoDB(ctx.request.headers.custom)

Exemple d'en-tête multiple

Vous pouvez également transmettre plusieurs en-têtes dans une seule demande et y accéder dans le gestionnaire de résolution. Par exemple, si l'customen-tête est défini avec deux valeurs :

curl -XPOST -H "Content-Type:application/graphql" -H "custom:bailey" -H "custom:nadia" -H "x-api-key:<API-KEY-VALUE>" -d '{"query":"mutation { createEvent(name: \"demo\", when: \"Next Friday!\", where: \"Here!\") {id name when where description}}"}' https://<ENDPOINT>/graphql

Vous pouvez ensuite y accéder comme s'il s'agissait d'un tableau : par exemple, ctx.request.headers.custom[1].

Accédez au nom de domaine personnalisé de la demande

AWS AppSync prend en charge la configuration d'un domaine personnalisé que vous pouvez utiliser pour accéder à votre GraphQL et à vos points de terminaison en temps réel. APIs Lorsque vous faites une demande avec un nom de domaine personnalisé, vous pouvez obtenir le nom de domaine en utilisantctx.request.domainName.

Lorsque vous utilisez le nom de domaine du point de terminaison GraphQL par défaut, la valeur est. null

Infos

La section info contient des informations sur la demande GraphQL. Cette section se présente sous la forme suivante :

type Info = {
  fieldName: string;
  parentTypeName: string;
  variables: any;
  selectionSetList: string[];
  selectionSetGraphQL: string;
};

Chaque champ est défini comme suit :

Par exemple, si vous résolvez le champ getPost de la requête suivante :

query {
  getPost(id: $postId) {
    postId
    title
    secondTitle: title
    content
    author(id: $authorId) {
      authorId
      name
    }
    secondAuthor(id: "789") {
      authorId
    }
    ... on Post {
      inlineFrag: comments: {
        id
      }
    }
    ... postFrag
  }
}

fragment postFrag on Post {
  postFrag: comments: {
    id
  }
}

La ctx.info variable complète disponible lors du traitement d'un gestionnaire peut alors être :

{
  "fieldName": "getPost",
  "parentTypeName": "Query",
  "variables": {
    "postId": "123",
    "authorId": "456"
  },
  "selectionSetList": [
    "postId",
    "title",
    "secondTitle"
    "content",
    "author",
    "author/authorId",
    "author/name",
    "secondAuthor",
    "secondAuthor/authorId",
    "inlineFragComments",
    "inlineFragComments/id",
    "postFragComments",
    "postFragComments/id"
  ],
  "selectionSetGraphQL": "{\n  getPost(id: $postId) {\n    postId\n    title\n    secondTitle: title\n    content\n    author(id: $authorId) {\n      authorId\n      name\n    }\n    secondAuthor(id: \"789\") {\n      authorId\n    }\n    ... on Post {\n      inlineFrag: comments {\n        id\n      }\n    }\n    ... postFrag\n  }\n}"
}

selectionSetListn'expose que les champs appartenant au type actuel. Si le type actuel est une interface ou une union, seuls les champs sélectionnés appartenant à l'interface sont exposés. Par exemple, selon le schéma suivant :

type Query {
    node(id: ID!): Node
}

interface Node {
    id: ID
}

type Post implements Node {
    id: ID
    title: String
    author: String
}

type Blog implements Node {
    id: ID
    title: String
    category: String
}

Et la requête suivante :

query {
    node(id: "post1") {
        id
        ... on Post {
            title
        }

        ... on Blog {
            title
        }
    }
}

Lors de l'appel ctx.info.selectionSetList à la résolution du Query.node champ, seul id est exposé :

"selectionSetList": [
    "id"
]