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.
# Configuration des résolveurs dans AWS AppSync
Dans les sections précédentes, vous avez appris à créer votre schéma GraphQL et votre source de données, puis à les lier ensemble dans le AWS AppSync service. Dans votre schéma, vous avez peut-être défini un ou plusieurs champs (opérations) dans votre requête et votre mutation. Bien que le schéma décrive les types de données que les opérations demanderaient à la source de données, il n'a jamais mis en œuvre le comportement de ces opérations en fonction des données.
Le comportement d'une opération est toujours implémenté dans le résolveur, qui sera lié au champ effectuant l'opération. Pour plus d'informations sur le fonctionnement général des résolveurs, consultez la page [Résolveurs](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html).
Dans AWS AppSync, votre résolveur est lié à un environnement d'exécution, qui est l'environnement dans lequel votre résolveur s'exécute. Les environnements d'exécution dictent la langue dans laquelle votre résolveur sera écrit. Deux environnements d'exécution sont actuellement pris en charge : APPSYNC\$1JS (JavaScript) et Apache Velocity Template Language (VTL).
Lors de la mise en œuvre de résolveurs, ils suivent une structure générale :
+ **Avant l'étape** : lorsqu'une demande est faite par le client, les données de la demande sont transmises aux résolveurs des champs de schéma utilisés (généralement vos requêtes, mutations, abonnements). Le résolveur commencera à traiter les données de la demande à l'aide d'un gestionnaire avant étape, qui permet d'effectuer certaines opérations de prétraitement avant que les données ne passent par le résolveur.
+ **Fonction (s)** : Une fois l'étape précédente exécutée, la demande est transmise à la liste des fonctions. La première fonction de la liste s'exécutera sur la source de données. Une fonction est un sous-ensemble du code de votre résolveur contenant son propre gestionnaire de requêtes et de réponses. Un gestionnaire de demandes prendra les données de la demande et effectuera des opérations sur la source de données. Le gestionnaire de réponses traitera la réponse de la source de données avant de la renvoyer à la liste. S'il existe plusieurs fonctions, les données de la demande seront envoyées à la fonction suivante de la liste à exécuter. Les fonctions de la liste seront exécutées en série dans l'ordre défini par le développeur. Une fois que toutes les fonctions ont été exécutées, le résultat final est transmis à l'étape suivante.
+ **Étape suivante** : L'étape suivante est une fonction de gestion qui vous permet d'effectuer certaines opérations finales sur la réponse de la fonction finale avant de la transmettre à la réponse GraphQL.
Ce flux est un exemple de résolveur de pipeline. Les résolveurs de pipeline sont pris en charge dans les deux environnements d'exécution. Cependant, il s'agit d'une explication simplifiée de ce que les résolveurs de pipeline peuvent faire. De plus, nous ne décrivons qu'une seule configuration de résolveur possible. Pour plus d'informations sur les configurations de résolveurs prises en charge, consultez l'aperçu des [JavaScript résolveurs pour APPSYNC\$1JS ou l'aperçu](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html) du modèle de mappage des [résolveurs](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-overview.html) pour VTL.
Comme vous pouvez le constater, les résolveurs sont modulaires. Pour que les composants du résolveur fonctionnent correctement, ils doivent être capables de vérifier l'état de l'exécution à partir d'autres composants. Dans la section [Résolveurs](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html), vous savez que chaque composant du résolveur peut recevoir des informations vitales sur l'état de l'exécution sous forme d'un ensemble d'arguments (`args`,`context`, etc.). En AWS AppSync, cela est géré strictement par le`context`. Il s'agit d'un conteneur contenant les informations relatives au champ en cours de résolution. Cela peut inclure tout, des arguments transmis aux résultats, aux données d'autorisation, aux données d'en-tête, etc. Pour plus d'informations sur le contexte, consultez la référence de l'[objet de contexte Resolver pour APPSYNC\$1JS ou la référence](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) de contexte du modèle de [mappage Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html) pour VTL.
Le contexte n'est pas le seul outil que vous pouvez utiliser pour implémenter votre résolveur. AWS AppSync prend en charge un large éventail d'utilitaires pour la génération de valeur, la gestion des erreurs, l'analyse syntaxique, la conversion, etc. [Vous pouvez voir une liste d'utilitaires [ici](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference-js.html) pour APPSYNC\$1JS ou ici pour VTL.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference.html)
Dans les sections suivantes, vous allez apprendre à configurer les résolveurs dans votre API GraphQL.
**Topics**
+ [Création de requêtes de base (JavaScript)](configuring-resolvers-js.md)
+ [Création de requêtes de base (VTL)](configuring-resolvers.md)
# Création de requêtes de base (JavaScript)
Les résolveurs GraphQL connectent les champs d'un schéma de type à une source de données. Les résolveurs sont le mécanisme par lequel les demandes sont satisfaites.
Résolveurs AWS AppSync utilisés JavaScript pour convertir une expression GraphQL dans un format utilisable par la source de données. Les modèles de mappage peuvent également être écrits dans le [langage VTL (Apache Velocity Template Language)](https://velocity.apache.org/engine/2.0/vtl-reference.html) pour convertir une expression GraphQL dans un format utilisable par la source de données.
Cette section décrit comment configurer les résolveurs à l'aide JavaScript de. La section [Tutoriels sur les résolveurs (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/tutorials-js.html) propose des didacticiels approfondis sur la façon d'implémenter des résolveurs à l'aide de. JavaScript La section [Resolver reference (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html) fournit une explication des opérations utilitaires qui peuvent être utilisées avec les JavaScript résolveurs.
Nous vous recommandons de suivre ce guide avant d'essayer d'utiliser l'un des didacticiels mentionnés ci-dessus.
Dans cette section, nous expliquerons comment créer et configurer des résolveurs pour les requêtes et les mutations.
**Note**
Ce guide part du principe que vous avez créé votre schéma et que vous avez au moins une requête ou une mutation. Si vous recherchez des abonnements (données en temps réel), consultez [ce](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html) guide.
Dans cette section, nous allons fournir quelques étapes générales pour configurer les résolveurs, ainsi qu'un exemple utilisant le schéma ci-dessous :
```
// schema.graphql file
input CreatePostInput {
title: String
date: AWSDateTime
}
type Post {
id: ID!
title: String
date: AWSDateTime
}
type Mutation {
createPost(input: CreatePostInput!): Post
}
type Query {
getPost: [Post]
}
```
## Création de résolveurs de requêtes de base
Cette section explique comment créer un résolveur de requêtes de base.
------
#### [ Console ]
1. Connectez-vous à la [AppSyncconsole AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Entrez les détails de votre schéma et de votre source de données. Consultez les sections [Conception de votre schéma](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) et [Attachement d'une source de données](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) pour plus d'informations.
1. À côté de l'éditeur de **schéma**, il y a une fenêtre appelée **Resolvers.** Cette zone contient une liste des types et des champs tels que définis dans votre fenêtre de **schéma**. Vous pouvez associer des résolveurs aux champs. Vous allez probablement associer des résolveurs à vos opérations sur le terrain. Dans cette section, nous allons examiner les configurations de requêtes simples. Sous le type de **requête**, choisissez **Joindre** à côté du champ de votre requête.
1. Sur la page **Attacher un résolveur**, sous **Type de résolveur**, vous pouvez choisir entre des résolveurs de type pipeline ou unitaire. Pour plus d'informations sur ces types, consultez la section [Résolveurs.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html) Ce guide utilisera`pipeline resolvers`.
**Astuce**
Lorsque vous créez des résolveurs de pipeline, vos sources de données seront associées aux fonctions de pipeline. Les fonctions sont créées une fois que vous avez créé le résolveur de pipeline lui-même, c'est pourquoi il n'est pas possible de le définir dans cette page. Si vous utilisez un résolveur d'unités, la source de données est directement liée au résolveur. Vous devez donc la définir dans cette page.
Pour **Resolver Runtime**, choisissez `APPSYNC_JS` d'activer le JavaScript runtime.
1. Vous pouvez activer la [mise en cache](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) pour cette API. Nous vous recommandons de désactiver cette fonctionnalité pour le moment. Choisissez **Créer**.
1. Sur la page **Modifier le résolveur**, il existe un éditeur de code appelé **Resolver code** qui vous permet d'implémenter la logique du gestionnaire de résolution et de la réponse (avant et après les étapes). Pour plus d'informations, consultez la [présentation des JavaScript résolveurs](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html).
**Note**
Dans notre exemple, nous allons simplement laisser la demande vide et la réponse définie pour renvoyer le dernier résultat de la source de données à partir du [contexte](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) :
```
import {util} from '@aws-appsync/utils';
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
```
Sous cette section, il y a un tableau appelé **Fonctions**. Les fonctions vous permettent d'implémenter du code qui peut être réutilisé dans plusieurs résolveurs. Au lieu de constamment réécrire ou copier le code, vous pouvez stocker le code source sous forme de fonction à ajouter à un résolveur chaque fois que vous en avez besoin.
Les fonctions constituent l'essentiel de la liste des opérations d'un pipeline. Lorsque vous utilisez plusieurs fonctions dans un résolveur, vous définissez l'ordre des fonctions, et elles seront exécutées dans cet ordre de manière séquentielle. Ils sont exécutés après l'exécution de la fonction de demande et avant le début de la fonction de réponse.
Pour ajouter une nouvelle fonction, sous **Fonctions**, choisissez **Ajouter une fonction**, puis **Créer une nouvelle fonction**. Vous pouvez également voir un bouton **Créer une fonction** pour choisir à la place.
1. Choisissez une source de données. Il s'agira de la source de données sur laquelle le résolveur agira.
**Note**
Dans notre exemple, nous attachons un résolveur pour`getPost`, qui récupère un `Post` objet par. `id` Supposons que nous ayons déjà configuré une table DynamoDB pour ce schéma. Sa clé de partition est définie sur `id` et est vide.
1. Entrez un`Function name`.
1. Sous **Code de fonction**, vous devez implémenter le comportement de la fonction. Cela peut prêter à confusion, mais chaque fonction aura son propre gestionnaire de requêtes et de réponses local. La demande est exécutée, puis la source de données est invoquée pour traiter la demande, puis la réponse de la source de données est traitée par le gestionnaire de réponses. Le résultat est stocké dans l'objet de [contexte](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html). Ensuite, la fonction suivante de la liste s'exécutera ou sera transmise au gestionnaire de réponses après étape s'il s'agit de la dernière.
**Note**
Dans notre exemple, nous attachons un résolveur à`getPost`, qui obtient une liste d'`Post`objets à partir de la source de données. Notre fonction de requête demandera les données de notre table, la table transmettra sa réponse au contexte (ctx), puis la réponse renverra le résultat dans le contexte. AWS AppSync Sa force réside dans son interconnexion avec les autres AWS services. Comme nous utilisons DynamoDB, nous disposons d'[une suite d'opérations pour simplifier ce type de](https://docs.aws.amazon.com/appsync/latest/devguide/js-resolver-reference-dynamodb.html) choses. Nous avons également quelques exemples standard pour d'autres types de sources de données.
Notre code ressemblera à ceci :
```
import { util } from '@aws-appsync/utils';
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
return { operation: 'Scan' };
}
/**
* return a list of scanned post items
*/
export function response(ctx) {
return ctx.result.items;
}
```
Au cours de cette étape, nous avons ajouté deux fonctions :
`request`: Le gestionnaire de demandes effectue l'opération de récupération par rapport à la source de données. L'argument contient l'objet contextuel (`ctx`) ou certaines données accessibles à tous les résolveurs effectuant une opération particulière. Par exemple, il peut contenir des données d'autorisation, les noms de champs en cours de résolution, etc. L'instruction return exécute une [https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-scan](https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-scan)opération (voir [ici](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html) pour des exemples). Comme nous travaillons avec DynamoDB, nous sommes autorisés à utiliser certaines des opérations de ce service. L'analyse effectue une extraction de base de tous les éléments de notre tableau. Le résultat de cette opération est stocké dans l'objet de contexte sous forme de `result` conteneur avant d'être transmis au gestionnaire de réponses. Le `request` est exécuté avant la réponse dans le pipeline.
`response`: le gestionnaire de réponses qui renvoie le résultat du`request`. L'argument est l'objet de contexte mis à jour et l'instruction de retour est`ctx.prev.result`. À ce stade du guide, cette valeur ne vous est peut-être pas familière. `ctx`fait référence à l'objet de contexte. `prev`fait référence à l'opération précédente dans le pipeline, qui était la nôtre`request`. `result`Il contient le ou les résultats du résolveur lorsqu'il se déplace dans le pipeline. Si vous mettez le tout ensemble, `ctx.prev.result` il renvoie le résultat de la dernière opération effectuée, à savoir le gestionnaire de demandes.
1. Choisissez **Créer une** fois que vous avez terminé.
1. De retour sur l'écran du résolveur, sous **Fonctions**, choisissez le menu déroulant **Ajouter une fonction** et ajoutez votre fonction à votre liste de fonctions.
1. Choisissez **Enregistrer** pour mettre à jour le résolveur.
------
#### [ CLI ]
**Pour ajouter votre fonction**
+ Créez une fonction pour votre résolveur de pipeline à l'aide de la `[create-function](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-function.html)` commande.
Vous devez entrer quelques paramètres pour cette commande en particulier :
1. Celui `api-id` de votre API.
1. Le `name` de la fonction dans la AWS AppSync console.
1. Le `data-source-name` ou le nom de la source de données que la fonction utilisera. Il doit déjà être créé et lié à votre API GraphQL dans le AWS AppSync service.
1. L'`runtime`environnement ou le langage de la fonction. Car JavaScript le nom doit être`APPSYNC_JS`, et le runtime,`1.0.0`.
1. Les `code` gestionnaires de requêtes et de réponses de votre fonction. Bien que vous puissiez le saisir manuellement, il est beaucoup plus facile de l'ajouter à un fichier .txt (ou dans un format similaire), puis de le transmettre en tant qu'argument.
**Note**
Notre code de requête se trouvera dans un fichier transmis en argument :
```
import { util } from '@aws-appsync/utils';
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
return { operation: 'Scan' };
}
/**
* return a list of scanned post items
*/
export function response(ctx) {
return ctx.result.items;
}
```
Voici un exemple de commande :
```
aws appsync create-function \
--api-id abcdefghijklmnopqrstuvwxyz \
--name get_posts_func_1 \
--data-source-name table-for-posts \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file://~/path/to/file/{filename}.{fileType}
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"functionConfiguration": {
"functionId": "ejglgvmcabdn7lx75ref4qeig4",
"functionArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/functions/ejglgvmcabdn7lx75ref4qeig4",
"name": "get_posts_func_1",
"dataSourceName": "table-for-posts",
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output goes here"
}
}
```
**Note**
Assurez-vous de l'enregistrer `functionId` quelque part car cela sera utilisé pour associer la fonction au résolveur.
**Pour créer votre résolveur**
+ Créez une fonction de pipeline pour `Query` en exécutant la `[create-resolver](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)` commande.
Vous devez entrer quelques paramètres pour cette commande en particulier :
1. Celui `api-id` de votre API.
1. Le `type-name` ou le type d'objet spécial dans votre schéma (requête, mutation, abonnement).
1. L'`field-name`opération ou l'opération sur le terrain à l'intérieur du type d'objet spécial auquel vous souhaitez associer le résolveur.
1. Le`kind`, qui spécifie un résolveur d'unité ou de pipeline. Définissez ce paramètre sur `PIPELINE` pour activer les fonctions de pipeline.
1. La `pipeline-config` ou les fonctions à associer au résolveur. Assurez-vous de connaître les `functionId` valeurs de vos fonctions. L'ordre d'inscription est important.
1. Le`runtime`, qui était `APPSYNC_JS` (JavaScript). L'est `runtimeVersion` actuellement`1.0.0`.
1. Le`code`, qui contient les gestionnaires d'étapes avant et après.
**Note**
Notre code de requête se trouvera dans un fichier transmis en argument :
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
const { id, ...values } = ctx.args;
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({ id }),
attributeValues: util.dynamodb.toMapValues(values),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Voici un exemple de commande :
```
aws appsync create-resolver \
--api-id abcdefghijklmnopqrstuvwxyz \
--type-name Query \
--field-name getPost \
--kind PIPELINE \
--pipeline-config functions=ejglgvmcabdn7lx75ref4qeig4 \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file:///path/to/file/{filename}.{fileType}
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"resolver": {
"typeName": "Mutation",
"fieldName": "getPost",
"resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation/resolvers/getPost",
"kind": "PIPELINE",
"pipelineConfig": {
"functions": [
"ejglgvmcabdn7lx75ref4qeig4"
]
},
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output goes here"
}
}
```
------
#### [ CDK ]
**Astuce**
Avant d'utiliser le CDK, nous vous recommandons de consulter la [documentation officielle du CDK ainsi que la](https://docs.aws.amazon.com/cdk/v2/guide/home.html) référence AWS AppSync du [CDK](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html).
Les étapes répertoriées ci-dessous ne montreront qu'un exemple général de l'extrait de code utilisé pour ajouter une ressource particulière. Cela **n'est pas** censé être une solution fonctionnelle dans votre code de production. Nous partons également du principe que vous disposez déjà d'une application fonctionnelle.
Une application de base nécessite les éléments suivants :
1. Directives d'importation de services
1. Code de schéma
1. Générateur de sources de données
1. Code de fonction
1. Code du résolveur
Dans les sections [Conception de votre schéma](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) et [Attachement d'une source de données](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html), nous savons que le fichier de pile inclura les directives d'importation du formulaire :
```
import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'
```
**Note**
Dans les sections précédentes, nous avons uniquement indiqué comment importer des AWS AppSync constructions. Dans le code réel, vous devrez importer davantage de services juste pour exécuter l'application. Dans notre exemple, si nous devions créer une application CDK très simple, nous importerions au moins le AWS AppSync service avec notre source de données, qui était une table DynamoDB. Nous aurions également besoin d'importer des constructions supplémentaires pour déployer l'application :
```
import * as cdk from 'aws-cdk-lib';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';
```
Pour résumer chacune d'entre elles :
`import * as cdk from 'aws-cdk-lib';`: Cela vous permet de définir votre application CDK et des constructions telles que la pile. Il contient également des fonctions utilitaires utiles pour notre application, telles que la manipulation des métadonnées. Si vous connaissez cette directive d'importation, mais que vous vous demandez pourquoi la bibliothèque principale cdk n'est pas utilisée ici, consultez la page de [migration](https://docs.aws.amazon.com/cdk/v2/guide/migrating-v2.html).
`import * as appsync from 'aws-cdk-lib/aws-appsync';`: Cela permet d'importer le [AWS AppSync service](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html).
`import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';`: Ceci importe le service [DynamoDB](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_dynamodb-readme.html).
`import { Construct } from 'constructs';`: Nous en avons besoin pour définir la [construction](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html) racine.
Le type d'importation dépend des services que vous appelez. Nous vous recommandons de consulter la documentation du CDK pour obtenir des exemples. Le schéma en haut de la page sera un fichier distinct dans votre application CDK sous forme de `.graphql` fichier. Dans le fichier de pile, nous pouvons l'associer à un nouveau GraphQL sous la forme :
```
const add_api = new appsync.GraphqlApi(this, 'graphQL-example', {
name: 'my-first-api',
schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql')),
});
```
**Note**
Dans le cadre de `add_api` ce projet, nous ajoutons une nouvelle API GraphQL en utilisant le `new` mot clé suivi de. `appsync.GraphqlApi(scope: Construct, id: string , props: GraphqlApiProps)` Notre champ d'application est `this` le suivant : l'identifiant CFN est`graphQL-example`, et nos accessoires sont `my-first-api` (nom de l'API dans la console) et `schema.graphql` (le chemin absolu vers le fichier de schéma).
Pour ajouter une source de données, vous devez d'abord ajouter votre source de données à la pile. Ensuite, vous devez l'associer à l'API GraphQL en utilisant la méthode spécifique à la source. L'association se produira lorsque vous ferez fonctionner votre résolveur. En attendant, prenons un exemple en créant la table DynamoDB en utilisant : `dynamodb.Table`
```
const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
});
```
**Note**
Si nous devions l'utiliser dans notre exemple, nous ajouterions une nouvelle table DynamoDB avec l'identifiant CFN de et une clé `posts-table` de partition de. `id (S)`
Ensuite, nous devons implémenter notre résolveur dans le fichier de pile. Voici un exemple de requête simple qui recherche tous les éléments d'une table DynamoDB :
```
const add_func = new appsync.AppsyncFunction(this, 'func-get-posts', {
name: 'get_posts_func_1',
add_api,
dataSource: add_api.addDynamoDbDataSource('table-for-posts', add_ddb_table),
code: appsync.Code.fromInline(`
export function request(ctx) {
return { operation: 'Scan' };
}
export function response(ctx) {
return ctx.result.items;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
});
new appsync.Resolver(this, 'pipeline-resolver-get-posts', {
add_api,
typeName: 'Query',
fieldName: 'getPost',
code: appsync.Code.fromInline(`
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
pipelineConfig: [add_func],
});
```
**Note**
Tout d'abord, nous avons créé une fonction appelée`add_func`. Cet ordre de création peut sembler un peu paradoxal, mais vous devez créer les fonctions dans votre résolveur de pipeline avant de créer le résolveur lui-même. Une fonction se présente sous la forme suivante :
```
AppsyncFunction(scope: Construct, id: string, props: AppsyncFunctionProps)
```
Notre champ d'application était`this`, notre identifiant CFN l'était`func-get-posts`, et nos accessoires contenaient les détails de la fonction réelle. À l'intérieur des accessoires, nous avons inclus :
La `name` fonction qui sera présente dans la AWS AppSync console (`get_posts_func_1`).
L'API GraphQL que nous avons créée précédemment ()`add_api`.
La source de données ; c'est le point où nous lions la source de données à la valeur de l'API GraphQL, puis nous l'associons à la fonction. Nous prenons la table que nous avons créée (`add_ddb_table`) et l'attachons à l'API GraphQL (`add_api`) en utilisant l'une des `GraphqlApi` méthodes ([https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.GraphqlApi.html#addwbrdynamowbrdbwbrdatawbrsourceid-table-options](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.GraphqlApi.html#addwbrdynamowbrdbwbrdatawbrsourceid-table-options)). La valeur id (`table-for-posts`) est le nom de la source de données dans la AWS AppSync console. Pour obtenir la liste des méthodes spécifiques à la source, consultez les pages suivantes :
[ DynamoDbDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.DynamoDbDataSource.html)
[ EventBridgeDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.EventBridgeDataSource.html)
[ HttpDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.HttpDataSource.html)
[ LambdaDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.LambdaDataSource.html)
[ NoneDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.NoneDataSource.html)
[ OpenSearchDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.OpenSearchDataSource.html)
[ RdsDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.RdsDataSource.html)
Le code contient les gestionnaires de demandes et de réponses de notre fonction, à savoir un simple scan et un retour.
Le runtime indique que nous voulons utiliser le runtime APPSYNC\$1JS version 1.0.0. Notez qu'il s'agit actuellement de la seule version disponible pour APPSYNC\$1JS.
Ensuite, nous devons associer la fonction au résolveur de pipeline. Nous avons créé notre résolveur en utilisant le formulaire :
```
Resolver(scope: Construct, id: string, props: ResolverProps)
```
Notre champ d'application était`this`, notre identifiant CFN l'était`pipeline-resolver-get-posts`, et nos accessoires contenaient les détails de la fonction réelle. À l'intérieur des accessoires, nous avons inclus :
L'API GraphQL que nous avons créée précédemment ()`add_api`.
Le nom du type d'objet spécial ; il s'agit d'une opération de requête, nous avons donc simplement ajouté la valeur`Query`.
Le nom du champ (`getPost`) est le nom du champ dans le schéma sous le `Query` type.
Le code contient vos gestionnaires avant et après. Notre exemple renvoie simplement les résultats qui se trouvaient dans le contexte une fois que la fonction a effectué son opération.
Le runtime indique que nous voulons utiliser le runtime APPSYNC\$1JS version 1.0.0. Notez qu'il s'agit actuellement de la seule version disponible pour APPSYNC\$1JS.
La configuration du pipeline contient la référence à la fonction que nous avons créée (`add_func`).
------
Pour résumer ce qui s'est passé dans cet exemple, vous avez vu une AWS AppSync fonction implémentant un gestionnaire de requêtes et de réponses. La fonction était chargée d'interagir avec votre source de données. Le gestionnaire de demandes a envoyé une `Scan` opération à AWS AppSync, lui indiquant quelle opération effectuer sur votre source de données DynamoDB. Le gestionnaire de réponses a renvoyé la liste des éléments (`ctx.result.items`). La liste des éléments a ensuite été automatiquement mappée au type `Post` GraphQL.
## Création de résolveurs de mutations de base
Cette section vous montrera comment créer un résolveur de mutations de base.
------
#### [ Console ]
1. Connectez-vous à la [AppSyncconsole AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Dans la section **Résolveurs** et dans le type de **mutation**, choisissez **Attacher** à côté de votre champ.
**Note**
Dans notre exemple, nous attachons un résolveur pour`createPost`, qui ajoute un `Post` objet à notre tableau. Supposons que nous utilisions la même table DynamoDB que celle de la section précédente. Sa clé de partition est définie sur `id` et est vide.
1. Sur la page **Joindre un résolveur**, sous **Type de résolveur, sélectionnez**. `pipeline resolvers` Pour rappel, vous trouverez plus d'informations sur les résolveurs [ici](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html). Pour **Resolver Runtime**, choisissez `APPSYNC_JS` d'activer le JavaScript runtime.
1. Vous pouvez activer la [mise en cache](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) pour cette API. Nous vous recommandons de désactiver cette fonctionnalité pour le moment. Choisissez **Créer**.
1. Choisissez **Ajouter une fonction**, puis **Créer une nouvelle fonction**. Vous pouvez également voir un bouton **Créer une fonction** pour choisir à la place.
1. Choisissez votre source de données . Il doit s'agir de la source dont vous allez manipuler les données avec la mutation.
1. Entrez un`Function name`.
1. Sous **Code de fonction**, vous devez implémenter le comportement de la fonction. Comme il s'agit d'une mutation, la demande effectuera idéalement une opération de changement d'état sur la source de données invoquée. Le résultat sera traité par la fonction de réponse.
**Note**
`createPost`c'est ajouter, ou « mettre », un nouveau `Post` dans le tableau avec nos paramètres comme données. Nous pourrions ajouter quelque chose comme ceci :
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Au cours de cette étape, nous avons également ajouté `request` des `response` fonctionnalités :
`request`: Le gestionnaire de requêtes accepte le contexte comme argument. L'instruction return du gestionnaire de requêtes exécute une [https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-putitem](https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-putitem)commande, qui est une opération DynamoDB intégrée ([voir](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-2.html) ici [ou](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html#WorkingWithItems.WritingData) ici pour des exemples). La `PutItem` commande ajoute un `Post` objet à notre table DynamoDB en prenant la valeur de la `key` partition (générée automatiquement `util.autoid()` par) `attributes` et à partir de l'argument de contexte saisi (ce sont les valeurs que nous transmettrons dans notre demande). Les arguments du `title` champ `key` est `id` `date` et `attributes` sont le et. Ils sont tous deux préformatés via l'[https://docs.aws.amazon.com//appsync/latest/devguide/dynamodb-helpers-in-util-dynamodb-js.html#utility-helpers-in-toMap-js](https://docs.aws.amazon.com//appsync/latest/devguide/dynamodb-helpers-in-util-dynamodb-js.html#utility-helpers-in-toMap-js)assistant pour fonctionner avec la table DynamoDB.
`response`: La réponse accepte le contexte mis à jour et renvoie le résultat du gestionnaire de demandes.
1. Choisissez **Créer une** fois que vous avez terminé.
1. De retour sur l'écran du résolveur, sous **Fonctions**, choisissez le menu déroulant **Ajouter une fonction** et ajoutez votre fonction à votre liste de fonctions.
1. Choisissez **Enregistrer** pour mettre à jour le résolveur.
------
#### [ CLI ]
**Pour ajouter votre fonction**
+ Créez une fonction pour votre résolveur de pipeline à l'aide de la `[create-function](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-function.html)` commande.
Vous devez entrer quelques paramètres pour cette commande en particulier :
1. Celui `api-id` de votre API.
1. Le `name` de la fonction dans la AWS AppSync console.
1. Le `data-source-name` ou le nom de la source de données que la fonction utilisera. Il doit déjà être créé et lié à votre API GraphQL dans le AWS AppSync service.
1. L'`runtime`environnement ou le langage de la fonction. Car JavaScript le nom doit être`APPSYNC_JS`, et le runtime,`1.0.0`.
1. Les `code` gestionnaires de requêtes et de réponses de votre fonction. Bien que vous puissiez le saisir manuellement, il est beaucoup plus facile de l'ajouter à un fichier .txt (ou dans un format similaire) puis de le transmettre comme argument.
**Note**
Notre code de requête se trouvera dans un fichier transmis en argument :
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Voici un exemple de commande :
```
aws appsync create-function \
--api-id abcdefghijklmnopqrstuvwxyz \
--name add_posts_func_1 \
--data-source-name table-for-posts \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file:///path/to/file/{filename}.{fileType}
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"functionConfiguration": {
"functionId": "vulcmbfcxffiram63psb4dduoa",
"functionArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/functions/vulcmbfcxffiram63psb4dduoa",
"name": "add_posts_func_1",
"dataSourceName": "table-for-posts",
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output foes here"
}
}
```
**Note**
Assurez-vous de l'enregistrer `functionId` quelque part car cela sera utilisé pour associer la fonction au résolveur.
**Pour créer votre résolveur**
+ Créez une fonction de pipeline pour `Mutation` en exécutant la `[create-resolver](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)` commande.
Vous devez entrer quelques paramètres pour cette commande en particulier :
1. Celui `api-id` de votre API.
1. Le `type-name` ou le type d'objet spécial dans votre schéma (requête, mutation, abonnement).
1. L'`field-name`opération ou l'opération sur le terrain à l'intérieur du type d'objet spécial auquel vous souhaitez associer le résolveur.
1. Le`kind`, qui spécifie un résolveur d'unité ou de pipeline. Définissez ce paramètre sur `PIPELINE` pour activer les fonctions de pipeline.
1. La `pipeline-config` ou les fonctions à associer au résolveur. Assurez-vous de connaître les `functionId` valeurs de vos fonctions. L'ordre d'inscription est important.
1. Le`runtime`, qui était `APPSYNC_JS` (JavaScript). L'est `runtimeVersion` actuellement`1.0.0`.
1. Le`code`, qui contient les étapes avant et après.
**Note**
Notre code de requête se trouvera dans un fichier transmis en argument :
```
import { util } from '@aws-appsync/utils';
/**
* Sends a request to `put` an item in the DynamoDB data source
*/
export function request(ctx) {
const { id, ...values } = ctx.args;
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({ id }),
attributeValues: util.dynamodb.toMapValues(values),
};
}
/**
* returns the result of the `put` operation
*/
export function response(ctx) {
return ctx.result;
}
```
Voici un exemple de commande :
```
aws appsync create-resolver \
--api-id abcdefghijklmnopqrstuvwxyz \
--type-name Mutation \
--field-name createPost \
--kind PIPELINE \
--pipeline-config functions=vulcmbfcxffiram63psb4dduoa \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
--code file:///path/to/file/{filename}.{fileType}
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"resolver": {
"typeName": "Mutation",
"fieldName": "createPost",
"resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation/resolvers/createPost",
"kind": "PIPELINE",
"pipelineConfig": {
"functions": [
"vulcmbfcxffiram63psb4dduoa"
]
},
"maxBatchSize": 0,
"runtime": {
"name": "APPSYNC_JS",
"runtimeVersion": "1.0.0"
},
"code": "Code output goes here"
}
}
```
------
#### [ CDK ]
**Astuce**
Avant d'utiliser le CDK, nous vous recommandons de consulter la [documentation officielle du CDK ainsi que la](https://docs.aws.amazon.com/cdk/v2/guide/home.html) référence AWS AppSync du [CDK](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html).
Les étapes répertoriées ci-dessous ne montreront qu'un exemple général de l'extrait de code utilisé pour ajouter une ressource particulière. Cela **n'est pas** censé être une solution fonctionnelle dans votre code de production. Nous partons également du principe que vous disposez déjà d'une application fonctionnelle.
+ Pour effectuer une mutation, en supposant que vous participez au même projet, vous pouvez l'ajouter au fichier de pile comme dans la requête. Voici une fonction modifiée et un résolveur pour une mutation qui ajoute un nouveau élément `Post` à la table :
```
const add_func_2 = new appsync.AppsyncFunction(this, 'func-add-post', {
name: 'add_posts_func_1',
add_api,
dataSource: add_api.addDynamoDbDataSource('table-for-posts-2', add_ddb_table),
code: appsync.Code.fromInline(`
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({id: util.autoId()}),
attributeValues: util.dynamodb.toMapValues(ctx.args.input),
};
}
export function response(ctx) {
return ctx.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
});
new appsync.Resolver(this, 'pipeline-resolver-create-posts', {
add_api,
typeName: 'Mutation',
fieldName: 'createPost',
code: appsync.Code.fromInline(`
export function request(ctx) {
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
`),
runtime: appsync.FunctionRuntime.JS_1_0_0,
pipelineConfig: [add_func_2],
});
```
**Note**
Comme cette mutation et la requête sont structurées de la même manière, nous allons simplement expliquer les modifications que nous avons apportées pour effectuer la mutation.
Dans la fonction, nous avons changé l'identifiant CFN `func-add-post` et le nom `add_posts_func_1` pour refléter le fait que nous ajoutons `Posts` à la table. Dans la source de données, nous avons créé une nouvelle association avec notre table (`add_ddb_table`) dans la AWS AppSync console, `table-for-posts-2` car la `addDynamoDbDataSource` méthode l'exige. N'oubliez pas que cette nouvelle association utilise toujours la même table que celle que nous avons créée précédemment, mais que nous disposons désormais de deux connexions dans la AWS AppSync console : une pour la requête as `table-for-posts` et une pour la mutation as`table-for-posts-2`. Le code a été modifié pour ajouter un `Post` en générant sa `id` valeur automatiquement et en acceptant les entrées d'un client pour le reste des champs.
Dans le résolveur, nous avons modifié la valeur de l'identifiant `pipeline-resolver-create-posts` pour refléter le fait que nous ajoutons `Posts` à la table. Pour refléter la mutation dans le schéma, le nom du type a été changé en`Mutation`, et le nom,`createPost`. La configuration du pipeline a été définie sur notre nouvelle fonction de mutation`add_func_2`.
------
Pour résumer ce qui se passe dans cet exemple, convertit AWS AppSync automatiquement les arguments définis dans le `createPost` champ à partir de votre schéma GraphQL en opérations DynamoDB. L'exemple stocke les enregistrements dans DynamoDB à l'aide d'une clé `id` de, qui est automatiquement créée à l'aide de notre assistant. `util.autoId()` Tous les autres champs que vous transmettez aux arguments de contexte (`ctx.args.input`) à partir de requêtes effectuées dans la AWS AppSync console ou autrement seront stockés en tant qu'attributs de la table. La clé et les attributs sont automatiquement mappés dans un format DynamoDB compatible à l'aide de l'assistant. `util.dynamodb.toMapValues(values)`
AWS AppSync prend également en charge les flux de travail de test et de débogage pour l'édition de résolveurs. Vous pouvez utiliser un `context` objet fictif pour voir la valeur transformée du modèle avant de l'invoquer. Vous pouvez éventuellement consulter la demande complète adressée à une source de données de manière interactive lorsque vous exécutez une requête. Pour plus d'informations, voir [Tester et déboguer les résolveurs (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/test-debug-resolvers-js.html) et [Surveillance et journalisation](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html#aws-appsync-monitoring).
## Résolveurs avancés
Si vous suivez la section facultative de pagination de la section [Conception de votre schéma](designing-your-schema.md#aws-appsync-designing-your-schema), vous devez tout de même ajouter votre résolveur à votre demande pour utiliser la pagination. Notre exemple a utilisé une pagination de requête appelée `getPosts` pour renvoyer uniquement une partie des éléments demandés à la fois. Le code de notre résolveur sur ce champ peut ressembler à ceci :
```
/**
* Performs a scan on the dynamodb data source
*/
export function request(ctx) {
const { limit = 20, nextToken } = ctx.args;
return { operation: 'Scan', limit, nextToken };
}
/**
* @returns the result of the `put` operation
*/
export function response(ctx) {
const { items: posts = [], nextToken } = ctx.result;
return { posts, nextToken };
}
```
Dans la demande, nous transmettons le contexte de la demande. Notre `limit` est*20*, ce qui signifie que nous renvoyons jusqu'à 20 `Posts` dans la première requête. Notre `nextToken` curseur est fixé sur la première `Post` entrée de la source de données. Ils sont transmis aux arguments. La demande effectue ensuite un scan depuis le premier `Post` jusqu'au nombre limite de scan. La source de données stocke le résultat dans le contexte, qui est transmis à la réponse. La réponse renvoie `Posts` le résultat récupéré, puis définit le `nextToken` is set sur l'`Post`entrée juste après la limite. La demande suivante est envoyée pour faire exactement la même chose, mais en commençant par le décalage juste après la première requête. N'oubliez pas que ces types de demandes sont effectués de manière séquentielle et non en parallèle.
# Tester et déboguer les résolveurs dans AWS AppSync () JavaScript
AWS AppSync exécute des résolveurs sur un champ GraphQL par rapport à une source de données. Lorsque vous travaillez avec des résolveurs de pipeline, les fonctions interagissent avec vos sources de données. Comme décrit dans la [présentation des JavaScript résolveurs](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html), les fonctions communiquent avec les sources de données à l'aide de gestionnaires de requêtes et de réponses écrits JavaScript et exécutés sur le `APPSYNC_JS` moteur d'exécution. Cela vous permet de fournir une logique et des conditions personnalisées avant et après la communication avec la source de données.
Pour aider les développeurs à écrire, tester et déboguer ces résolveurs, la AWS AppSync console fournit également des outils permettant de créer une requête et une réponse GraphQL avec des données fictives jusqu'au résolveur de champs individuel. En outre, vous pouvez effectuer des requêtes, des mutations et des abonnements dans la AWS AppSync console et consulter un journal détaillé de l'intégralité de la demande d'Amazon CloudWatch. Cela inclut les résultats de la source de données.
## Tester avec des données fictives
Lorsqu'un résolveur GraphQL est invoqué, il contient un `context` objet contenant des informations pertinentes sur la requête. Ces informations incluent les arguments d'un client, les informations d'identité et les données du champ GraphQL parent. Il stocke également les résultats de la source de données, qui peuvent être utilisés dans le gestionnaire de réponses. Pour plus d'informations sur cette structure et les utilitaires d'assistance disponibles à utiliser lors de la programmation, consultez la référence de l'[objet contextuel Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html).
Lorsque vous écrivez ou modifiez une fonction de résolution, vous pouvez transmettre un objet de *contexte *fictif* ou de test* à l'éditeur de console. Cela vous permet de voir comment les gestionnaires de demandes et de réponses s'évaluent sans réellement se heurter à une source de données. Par exemple, vous pouvez transmettre un argument de test `firstname: Shaggy` et voir comment il est analysé lors de l'utilisation de `ctx.args.firstname` dans votre modèle de code. Vous pouvez également tester l'évaluation de n'importe quelle annotation d'utilitaire telle que `util.autoId()` ou `util.time.nowISO8601()`.
### Tester les résolveurs
Cet exemple utilisera la AWS AppSync console pour tester les résolveurs.
1. Connectez-vous à la [AppSyncconsole AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, sélectionnez **Fonctions.**
1. Choisissez une fonction existante.
1. En haut de la page de la **fonction de mise à jour**, choisissez **Sélectionner le contexte de test**, puis sélectionnez **Créer un nouveau contexte**.
1. Sélectionnez un exemple d'objet de contexte ou renseignez le JSON manuellement dans la fenêtre **Configurer le contexte de test** ci-dessous.
1. Entrez un **nom de contexte de texte**.
1. Choisissez le bouton **Enregistrer**.
1. Pour évaluer votre résolveur à l'aide de cet objet de contexte simulé, choisissez **Exécuter test**
Pour un exemple plus pratique, supposons que vous disposiez d'une application stockant un type GraphQL `Dog` qui utilise la génération automatique d'identifiants pour les objets et les stocke dans Amazon DynamoDB. Vous souhaitez également écrire des valeurs à partir des arguments d'une mutation GraphQL et n'autoriser que certains utilisateurs à voir une réponse. L'extrait suivant montre à quoi pourrait ressembler le schéma :
```
type Dog {
breed: String
color: String
}
type Mutation {
addDog(firstname: String, age: Int): Dog
}
```
Vous pouvez écrire une AWS AppSync fonction et l'ajouter à votre `addDog` résolveur pour gérer la mutation. Pour tester votre AWS AppSync fonction, vous pouvez renseigner un objet de contexte comme dans l'exemple suivant. Le suivant possède les arguments `name` et `age` du client, ainsi qu'un `username` renseigné dans l'objet `identity` :
```
{
"arguments" : {
"firstname": "Shaggy",
"age": 4
},
"source" : {},
"result" : {
"breed" : "Miniature Schnauzer",
"color" : "black_grey"
},
"identity": {
"sub" : "uuid",
"issuer" : " https://cognito-idp.{region}.amazonaws.com/{userPoolId}",
"username" : "Nadia",
"claims" : { },
"sourceIp" :[ "x.x.x.x" ],
"defaultAuthStrategy" : "ALLOW"
}
}
```
Vous pouvez tester votre AWS AppSync fonction à l'aide du code suivant :
```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
return {
operation: 'PutItem',
key: util.dynamodb.toMapValues({ id: util.autoId() }),
attributeValues: util.dynamodb.toMapValues(ctx.args),
};
}
export function response(ctx) {
if (ctx.identity.username === 'Nadia') {
console.log("This request is allowed")
return ctx.result;
}
util.unauthorized();
}
```
Le gestionnaire de demandes et de réponses évalué contient les données de votre objet de contexte de test et la valeur générée à partir de`util.autoId()`. De plus, si vous deviez modifier `username` avec une valeur autre que `Nadia`, les résultats ne seront pas renvoyés, car le contrôle d'autorisation échouerait. Pour plus d'informations sur le contrôle d'accès détaillé, consultez la section Cas [d'utilisation des autorisations](security-authorization-use-cases.md#aws-appsync-security-authorization-use-cases).
### Tester les gestionnaires de demandes et de réponses avec AWS AppSync APIs
Vous pouvez utiliser la commande `EvaluateCode` API pour tester votre code à distance avec des données simulées. Pour commencer à utiliser la commande, assurez-vous d'avoir ajouté l'`appsync:evaluateMappingCode`autorisation à votre politique. Par exemple :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appsync:evaluateCode",
"Resource": "arn:aws:appsync:us-east-1:111122223333:*"
}
]
}
```
------
Vous pouvez utiliser la commande en utilisant le [AWS CLI](https://aws.amazon.com/cli/)ou [AWS SDKs](https://aws.amazon.com/tools/). Prenons l'exemple du `Dog` schéma et de ses gestionnaires de demandes et de réponses de AWS AppSync fonctions présentés dans la section précédente. À l'aide de la CLI de votre station locale, enregistrez le code dans un fichier nommé`code.js`, puis enregistrez l'`context`objet dans un fichier nommé`context.json`. Depuis votre shell, exécutez la commande suivante :
```
$ aws appsync evaluate-code \
--code file://code.js \
--function response \
--context file://context.json \
--runtime name=APPSYNC_JS,runtimeVersion=1.0.0
```
La réponse contient un `evaluationResult` contenant la charge utile renvoyée par votre gestionnaire. Il contient également un `logs` objet contenant la liste des journaux générés par votre gestionnaire lors de l'évaluation. Cela permet de déboguer facilement l'exécution de votre code et de consulter les informations relatives à votre évaluation pour vous aider à résoudre le problème. Par exemple :
```
{
"evaluationResult": "{\"breed\":\"Miniature Schnauzer\",\"color\":\"black_grey\"}",
"logs": [
"INFO - code.js:13:5: \"This request is allowed\""
]
}
```
Ils `evaluationResult` peuvent être analysés au format JSON, ce qui donne :
```
{
"breed": "Miniature Schnauzer",
"color": "black_grey"
}
```
À l'aide du SDK, vous pouvez facilement intégrer des tests issus de votre suite de tests préférée pour valider le comportement de vos gestionnaires. Nous vous recommandons de créer des tests à l'aide du [Jest Testing Framework](https://jestjs.io/), mais toutes les suites de tests fonctionnent. L'extrait suivant montre une exécution de validation hypothétique. Notez que nous nous attendons à ce que la réponse d'évaluation soit un JSON valide. Nous utilisons donc `JSON.parse` pour récupérer le JSON à partir de la réponse sous forme de chaîne :
```
const AWS = require('aws-sdk')
const fs = require('fs')
const client = new AWS.AppSync({ region: 'us-east-2' })
const runtime = {name:'APPSYNC_JS',runtimeVersion:'1.0.0')
test('request correctly calls DynamoDB', async () => {
const code = fs.readFileSync('./code.js', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')
const contextJSON = JSON.parse(context)
const response = await client.evaluateCode({ code, context, runtime, function: 'request' }).promise()
const result = JSON.parse(response.evaluationResult)
expect(result.key.id.S).toBeDefined()
expect(result.attributeValues.firstname.S).toEqual(contextJSON.arguments.firstname)
})
```
Cela donne le résultat suivant :
```
Ran all test suites.
> jest
PASS ./index.test.js
✓ request correctly calls DynamoDB (543 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 totalTime: 1.511 s, estimated 2 s
```
## Débogage d'une requête en direct
Rien ne remplace un end-to-end test et une journalisation pour déboguer une application de production. AWS AppSync vous permet de consigner les erreurs et de fournir les détails complets des demandes via Amazon CloudWatch. En outre, vous pouvez utiliser la AWS AppSync console pour tester les requêtes GraphQL, les mutations et les abonnements, ainsi que pour diffuser en direct les données du journal de chaque requête dans l'éditeur de requêtes afin de les déboguer en temps réel. Pour les abonnements, les journaux affichent les informations de temps de connexion.
Pour ce faire, vous devez activer Amazon CloudWatch Logs à l'avance, comme décrit dans [Surveillance et journalisation](monitoring.md#aws-appsync-monitoring). Ensuite, dans la AWS AppSync console, choisissez l'onglet **Requêtes**, puis entrez une requête GraphQL valide. Dans la section inférieure droite, cliquez et faites glisser la fenêtre **Logs** pour ouvrir la vue des logs. À l'aide de la flèche « Play » en haut de la page, exécutez votre requête GraphQL. Dans quelques instants, l'intégralité de vos journaux de demandes et de réponses relatifs à l'opération est diffusée dans cette section et vous pouvez les consulter dans la console.
# Configuration et utilisation des résolveurs de pipeline dans AWS AppSync () JavaScript
AWS AppSync exécute des résolveurs sur un champ GraphQL. Dans certains cas, les applications nécessitent l'exécution de plusieurs opérations pour résoudre un seul champ GraphQL. Avec les résolveurs de pipeline, les développeurs peuvent désormais composer des opérations appelées fonctions et les exécuter en séquence. Les résolveurs de pipeline sont utiles pour les applications qui, par exemple, doivent effectuer un contrôle d'autorisation avant d'extraire des données pour un champ.
Pour plus d'informations sur l'architecture d'un résolveur de JavaScript pipeline, consultez la présentation des [JavaScriptrésolveurs](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html#anatomy-of-a-pipeline-resolver-js).
## Étape 1 : Création d'un résolveur de pipeline
Dans la AWS AppSync console, accédez à la page **Schéma**.
Enregistrez le schéma suivant :
```
schema {
query: Query
mutation: Mutation
}
type Mutation {
signUp(input: Signup): User
}
type Query {
getUser(id: ID!): User
}
input Signup {
username: String!
email: String!
}
type User {
id: ID!
username: String
email: AWSEmail
}
```
Nous allons raccorder un résolveur de pipeline au champ **signUp** sur le type **Mutation**. Dans le champ Type de **mutation** sur le côté droit, choisissez **Attacher** à côté du champ de `signUp` mutation. Réglez le résolveur sur `pipeline resolver` et le `APPSYNC_JS` runtime, puis créez le résolveur.
Notre résolveur de pipeline inscrit un utilisateur en validant tout d'abord l'adresse e-mail saisie, puis en enregistrant l'utilisateur dans le système. **Nous allons encapsuler la validation de l'e-mail dans une fonction **ValidateEmail** et la sauvegarde de l'utilisateur dans une fonction SaveUser.** La fonction **validateEmail** s'exécute d'abord, puis si l'e-mail est valide, alors la fonction **saveUser** s'exécute.
Le flux d'exécution sera le suivant :
1. Gestionnaire de requêtes du résolveur Mutation.signup
1. Fonction validateEmail
1. Fonction saveUser
1. Gestionnaire de réponses du résolveur Mutation.signup
Comme nous réutiliserons probablement la fonction **ValidateEmail** dans d'autres résolveurs de notre API, nous voulons éviter d'`ctx.args`y accéder car ceux-ci changeront d'un champ GraphQL à l'autre. Au lieu de cela, nous pouvons utiliser le `ctx.stash` pour stocker l'attribut e-mail depuis l'argument de champ de saisie `signUp(input: Signup)`.
Mettez à jour le code de votre résolveur en remplaçant vos fonctions de demande et de réponse :
```
export function request(ctx) {
ctx.stash.email = ctx.args.input.email
return {};
}
export function response(ctx) {
return ctx.prev.result;
}
```
Choisissez **Créer** ou **Enregistrer** pour mettre à jour le résolveur.
## Étape 2 : Création d'une fonction
Sur la page du résolveur de pipeline, dans la section **Fonctions**, cliquez sur **Ajouter une fonction**, puis sur **Créer une nouvelle fonction**. Il est également possible de créer des fonctions sans passer par la page du résolveur ; pour cela, dans la AWS AppSync console, rendez-vous sur la page **Fonctions**. Choisissez le bouton **Créer une fonction**. Créons une fonction permettant de vérifier si un e-mail est valide et provient d'un domaine spécifique. Si l'e-mail n'est pas valide, la fonction renvoie une erreur. Dans le cas contraire, elle transmet les données saisies.
Assurez-vous d'avoir créé une source de données de type **NONE**. Choisissez cette source de données dans la liste des **noms des sources de données**. Entrez le **nom de la fonction**`validateEmail`. Dans la zone du **code de fonction**, remplacez tout par cet extrait de code :
```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
const { email } = ctx.stash;
const valid = util.matches(
'^[a-zA-Z0-9_.+-]+@(?:(?:[a-zA-Z0-9-]+\.)?[a-zA-Z]+\.)?(myvaliddomain)\.com',
email
);
if (!valid) {
util.error(`"${email}" is not a valid email.`);
}
return { payload: { email } };
}
export function response(ctx) {
return ctx.result;
}
```
Passez en revue vos entrées, puis choisissez **Create**. Nous venons de créer notre fonction **validateEmail**. Répétez ces étapes pour créer la fonction **SaveUser** avec le code suivant (Pour des raisons de simplicité, nous utilisons **une** source de données NONE et prétendons que l'utilisateur a été enregistré dans le système après l'exécution de la fonction. ) :
```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
return ctx.prev.result;
}
export function response(ctx) {
ctx.result.id = util.autoId();
return ctx.result;
}
```
Nous venons de créer notre fonction **SaveUser**.
## Étape 3 : Ajouter une fonction à un résolveur de pipeline
Nos fonctions auraient dû être ajoutées automatiquement au résolveur de pipeline que nous venons de créer. Si ce n'était pas le cas, ou si vous avez créé les fonctions via la page **Fonctions**, vous pouvez cliquer sur **Ajouter une fonction** sur la page du `signUp` résolveur pour les joindre. Ajoutez les fonctions **ValidateEmail** **et** SaveUser au résolveur. La fonction **validateEmail** doit être placée avant la fonction **saveUser**. Au fur et à mesure que vous ajoutez des fonctions, vous pouvez utiliser les options de **déplacement vers le haut** **et de déplacement vers le bas** pour réorganiser l'ordre d'exécution de vos fonctions. Passez en revue vos modifications, puis choisissez **Enregistrer**.
## Étape 4 : Exécution d'une requête
Dans la AWS AppSync console, accédez à la page **Requêtes**. Dans l'explorateur, assurez-vous d'utiliser votre mutation. Si ce n'est pas le cas, choisissez `Mutation` dans la liste déroulante, puis choisissez`+`. Entrez la requête suivante :
```
mutation {
signUp(input: {email: "nadia@myvaliddomain.com", username: "nadia"}) {
id
username
}
}
```
Cela devrait renvoyer quelque chose comme :
```
{
"data": {
"signUp": {
"id": "256b6cc2-4694-46f4-a55e-8cb14cc5d7fc",
"username": "nadia"
}
}
}
```
Nous avons inscrit notre utilisateur et validé l'e-mail saisi à l'aide d'un résolveur de pipeline.
# Création de requêtes de base (VTL)
**Note**
Nous prenons désormais principalement en charge le runtime APPSYNC\$1JS et sa documentation. [Pensez à utiliser le runtime APPSYNC\$1JS et ses guides ici.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)
Les résolveurs GraphQL connectent les champs d'un schéma de type à une source de données. Les résolveurs sont le mécanisme par lequel les demandes sont satisfaites. AWS AppSync peut créer et connecter automatiquement des résolveurs à partir d'un schéma ou créer un schéma et connecter des résolveurs à partir d'une table existante sans que vous ayez à écrire de code.
Résolveurs AWS AppSync utilisés JavaScript pour convertir une expression GraphQL dans un format utilisable par la source de données. Les modèles de mappage peuvent également être écrits dans le [langage VTL (Apache Velocity Template Language)](https://velocity.apache.org/engine/2.0/vtl-reference.html) pour convertir une expression GraphQL dans un format utilisable par la source de données.
Cette section explique comment configurer les résolveurs à l'aide de VTL. Un guide de programmation de type didacticiel d'introduction pour l'écriture de résolveurs se trouve dans le [guide de programmation du modèle de mappage Resolver](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide), et les utilitaires d'assistance disponibles pour la programmation se trouvent dans la référence contextuelle du modèle de mappage [Resolver](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference). AWS AppSync possède également des flux de test et de débogage intégrés que vous pouvez utiliser lorsque vous modifiez ou créez à partir de zéro. Pour plus d'informations, consultez la section [Tester et déboguer les résolveurs](test-debug-resolvers.md#aws-appsync-test-debug-resolvers).
Nous vous recommandons de suivre ce guide avant d'essayer d'utiliser l'un des didacticiels mentionnés ci-dessus.
Dans cette section, nous expliquerons comment créer un résolveur, ajouter un résolveur pour les mutations et utiliser des configurations avancées.
## Créez votre premier résolveur
En suivant les exemples des sections précédentes, la première étape consiste à créer un résolveur adapté à votre `Query` type.
------
#### [ Console ]
1. Connectez-vous à la [AppSync console AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Sur le côté droit de la page, il y a une fenêtre appelée **Resolvers**. Cette zone contient une liste des types et des champs tels que définis dans votre fenêtre de **schéma** sur le côté gauche de la page. Vous pouvez associer des résolveurs aux champs. Par exemple, sous le type de **requête**, choisissez **Joindre** à côté du `getTodos` champ.
1. Sur la page **Create Resolver**, choisissez la source de données que vous avez créée dans le guide [Joindre une source de données](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html). Dans la fenêtre **Configurer les modèles de mappage**, vous pouvez choisir à la fois les modèles de mappage de demande et de réponse génériques à l'aide de la liste déroulante de droite ou écrire le vôtre.
**Note**
L'appariement d'un modèle de mappage de demande à un modèle de mappage de réponse est appelé résolveur d'unités. Les résolveurs d'unités sont généralement conçus pour effectuer des opérations par cœur ; nous recommandons de les utiliser uniquement pour des opérations uniques avec un petit nombre de sources de données. Pour les opérations plus complexes, nous recommandons d'utiliser des résolveurs de pipeline, qui peuvent exécuter plusieurs opérations avec plusieurs sources de données de manière séquentielle.
Pour plus d'informations sur la différence entre les modèles de mappage de demandes et de réponses, consultez [Unit Resolvers](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-mapping-template-reference-overview.html#unit-resolvers).
Pour plus d'informations sur l'utilisation des résolveurs de pipeline, consultez la section [Résolveurs de pipeline](pipeline-resolvers.md#aws-appsync-pipeline-resolvers).
1. Pour les cas d'utilisation courants, la AWS AppSync console possède des modèles intégrés que vous pouvez utiliser pour obtenir des éléments à partir de sources de données (par exemple, toutes les requêtes relatives aux articles, les recherches individuelles, etc.). Par exemple, dans la version simple du schéma de [Designing your schema](designing-your-schema.md#aws-appsync-designing-your-schema) where `getTodos` didn't have pagination, le modèle de mappage des demandes pour la liste des éléments est le suivant :
```
{
"version" : "2017-02-28",
"operation" : "Scan"
}
```
1. Vous avez toujours besoin d'un modèle de mappage des réponses pour accompagner la demande. La console fournit un modèle par défaut avec la valeur de transmission suivante pour les listes :
```
$util.toJson($ctx.result.items)
```
Dans cet exemple, l'objet `context` (dont l'alias est `$ctx`) pour les listes d'éléments se présente sous la forme `$context.result.items`. Si votre opération GraphQL renvoie un seul élément, ce serait `$context.result`. AWS AppSync fournit des fonctions d'assistant pour les opérations courantes, notamment la fonction `$util.toJson` répertoriée précédemment, pour mettre correctement en forme les réponses. Pour obtenir la liste complète des fonctions, consultez la [référence de l'utilitaire de modèle de mappage Resolver](resolver-util-reference.md#aws-appsync-resolver-mapping-template-util-reference).
1. Choisissez **Save Resolver.**
------
#### [ API ]
1. Créez un objet résolveur en appelant l'[https://docs.aws.amazon.com/appsync/latest/APIReference/API_CreateResolver.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_CreateResolver.html)API.
1. Vous pouvez modifier les champs de votre résolveur en appelant l'[https://docs.aws.amazon.com/appsync/latest/APIReference/API_UpdateResolver.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_UpdateResolver.html)API.
------
#### [ CLI ]
1. Créez un résolveur en exécutant la [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)commande.
Vous devez saisir 6 paramètres pour cette commande particulière :
1. Celui `api-id` de votre API.
1. Le `type-name` type que vous souhaitez modifier dans votre schéma. Dans l'exemple de console, c'était le cas`Query`.
1. Le `field-name` champ que vous souhaitez modifier dans votre type. Dans l'exemple de console, c'était le cas`getTodos`.
1. La source `data-source-name` de données que vous avez créée dans le guide [Joindre une source de données](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html).
1. Le`request-mapping-template`, qui est le corps de la demande. Dans l'exemple de console, c'était :
```
{
"version" : "2017-02-28",
"operation" : "Scan"
}
```
1. Le`response-mapping-template`, qui est le corps de la réponse. Dans l'exemple de console, c'était :
```
$util.toJson($ctx.result.items)
```
Voici un exemple de commande :
```
aws appsync create-resolver --api-id abcdefghijklmnopqrstuvwxyz --type-name Query --field-name getTodos --data-source-name TodoTable --request-mapping-template "{ "version" : "2017-02-28", "operation" : "Scan", }" --response-mapping-template ""$"util.toJson("$"ctx.result.items)"
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"resolver": {
"kind": "UNIT",
"dataSourceName": "TodoTable",
"requestMappingTemplate": "{ version : 2017-02-28, operation : Scan, }",
"resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Query/resolvers/getTodos",
"typeName": "Query",
"fieldName": "getTodos",
"responseMappingTemplate": "$util.toJson($ctx.result.items)"
}
}
```
1. Pour modifier les modèles de and/or mappage de champs d'un résolveur, exécutez la [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-resolver.html)commande.
À l'exception du `api-id` paramètre, les paramètres utilisés dans la `create-resolver` commande seront remplacés par les nouvelles valeurs de la `update-resolver` commande.
------
## Ajouter un résolveur pour les mutations
L'étape suivante consiste à créer un résolveur adapté à votre `Mutation` type.
------
#### [ Console ]
1. Connectez-vous à la [AppSync console AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Sous le type de **mutation**, choisissez **Attacher** à côté du `addTodo` champ.
1. Sur la page **Create Resolver**, choisissez la source de données que vous avez créée dans le guide [Joindre une source de données](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html).
1. Dans la fenêtre **Configurer les modèles de mappage**, vous devez modifier le modèle de demande car il s'agit d'une mutation dans laquelle vous ajoutez un nouvel élément à DynamoDB. Utilisez le modèle de mappage de demande suivant :
```
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
},
"attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```
1. AWS AppSync convertit automatiquement les arguments définis dans le `addTodo` champ à partir de votre schéma GraphQL en opérations DynamoDB. L'exemple précédent stocke les enregistrements dans DynamoDB à l'aide d'une clé `id` de, qui est transmise par l'argument de mutation sous la forme. `$ctx.args.id` Tous les autres champs que vous traversez sont automatiquement mappés aux attributs DynamoDB avec. `$util.dynamodb.toMapValuesJson($ctx.args)`
Pour ce résolveur, utilisez ensuite le modèle de mappage de réponse suivant :
```
$util.toJson($ctx.result)
```
AWS AppSync prend également en charge les flux de travail de test et de débogage pour l'édition de résolveurs. Vous pouvez utiliser un objet `context` simulé pour afficher la valeur transformée du modèle avant l'appel. Le cas échéant, vous pouvez afficher l'intégralité de l'exécution de la requête sur une source de données de façon interactive lorsque vous exécutez une requête. Pour plus d'informations, consultez les sections [Tester et déboguer les résolveurs](test-debug-resolvers.md#aws-appsync-test-debug-resolvers) et [Surveillance et journalisation](monitoring.md#aws-appsync-monitoring).
1. Choisissez **Save Resolver.**
------
#### [ API ]
Vous pouvez également le faire APIs en utilisant les commandes de la section [Créez votre premier résolveur](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) et les détails des paramètres de cette section.
------
#### [ CLI ]
Vous pouvez également le faire dans la CLI en utilisant les commandes de la section [Créez votre premier résolveur](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) et les détails des paramètres de cette section.
------
À ce stade, si vous n'utilisez pas les résolveurs avancés, vous pouvez commencer à utiliser votre API GraphQL comme indiqué [dans Utilisation](using-your-api.md#aws-appsync-using-your-api) de votre API.
## Résolveurs avancés
Si vous suivez la section Avancé et que vous créez un exemple de schéma dans [Conception de votre schéma](designing-your-schema.md#aws-appsync-designing-your-schema) pour effectuer un scan paginé, utilisez plutôt le modèle de demande suivant pour le `getTodos` champ :
```
{
"version" : "2017-02-28",
"operation" : "Scan",
"limit": $util.defaultIfNull(${ctx.args.limit}, 20),
"nextToken": $util.toJson($util.defaultIfNullOrBlank($ctx.args.nextToken, null))
}
```
Pour ce scénario de pagination, le mappage de réponse est plus qu'une simple transmission, car il doit contenir à la fois le *curseur* (afin que le client sache quelle est la prochaine page à démarrer) et le jeu de résultats. Le modèle de mappage est ainsi :
```
{
"todos": $util.toJson($context.result.items),
"nextToken": $util.toJson($context.result.nextToken)
}
```
Les champs du précédent modèle de mappage de réponse doivent correspondre aux champs définis dans votre type `TodoConnection`.
Dans le cas de relations où vous avez une `Comments` table et que vous résolvez le champ de commentaires sur le `Todo` type (qui renvoie un type de`[Comment]`), vous pouvez utiliser un modèle de mappage qui exécute une requête sur la deuxième table. Pour ce faire, vous devez déjà avoir créé une source de données pour la `Comments` table, comme indiqué dans la section [Joindre une source de données](attaching-a-data-source.md#aws-appsync-getting-started-build-a-schema-from-scratch).
**Note**
Nous utilisons une opération de requête sur une deuxième table à des fins d'illustration uniquement. Vous pouvez utiliser une autre opération sur DynamoDB à la place. En outre, vous pouvez extraire les données d'une autre source de données, telle qu' AWS Lambda Amazon OpenSearch Service, car la relation est contrôlée par votre schéma GraphQL.
------
#### [ Console ]
1. Connectez-vous à la [AppSync console AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Sous le type **Todo**, choisissez **Joindre** à côté du `comments` champ.
1. Sur la page **Créer un résolveur**, choisissez la source de données de votre table de **commentaires**. Le nom par défaut du tableau des **commentaires** dans les guides de démarrage rapide est`AppSyncCommentTable`, mais il peut varier en fonction du nom que vous lui avez donné.
1. Ajoutez l'extrait suivant à votre modèle de mappage de demandes :
```
{
"version": "2017-02-28",
"operation": "Query",
"index": "todoid-index",
"query": {
"expression": "todoid = :todoid",
"expressionValues": {
":todoid": {
"S": $util.toJson($context.source.id)
}
}
}
}
```
1. Le `context.source` fait référence à l'objet parent du champ actif en cours de résolution. Dans cet exemple, `source.id` fait référence à l'objet `Todo` individuel, qui est ensuite utilisé pour l'expression de la requête.
Vous pouvez utiliser le modèle de mappage de réponse de transmission, comme suit :
```
$util.toJson($ctx.result.items)
```
1. Choisissez **Save Resolver.**
1. Enfin, revenez sur la page **Schéma** de la console, attachez un résolveur au `addComment` champ et spécifiez la source de données de la `Comments` table. Dans ce cas, le modèle de mappage de requête est un simple `PutItem` avec le `todoid` spécifique qui est commenté en tant qu'argument, mais vous utilisez l'utilitaire `$utils.autoId()` pour créer une clé de tri unique pour le commentaire de la façon suivante :
```
{
"version": "2017-02-28",
"operation": "PutItem",
"key": {
"todoid": { "S": $util.toJson($context.arguments.todoid) },
"commentid": { "S": "$util.autoId()" }
},
"attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```
Utilisez un modèle de réponse de transmission comme suit :
```
$util.toJson($ctx.result)
```
------
#### [ API ]
Vous pouvez également le faire APIs en utilisant les commandes de la section [Créez votre premier résolveur](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) et les détails des paramètres de cette section.
------
#### [ CLI ]
Vous pouvez également le faire dans la CLI en utilisant les commandes de la section [Créez votre premier résolveur](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) et les détails des paramètres de cette section.
------
# Désactivation des modèles de mappage VTL avec des résolveurs Lambda directs (VTL)
**Note**
Nous prenons désormais principalement en charge le runtime APPSYNC\$1JS et sa documentation. [Pensez à utiliser le runtime APPSYNC\$1JS et ses guides ici.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)
Avec les résolveurs Lambda directs, vous pouvez contourner l'utilisation de modèles de mappage VTL lorsque vous utilisez des sources de données. AWS Lambda AWS AppSync peut fournir une charge utile par défaut à votre fonction Lambda ainsi qu'une traduction par défaut de la réponse d'une fonction Lambda en un type GraphQL. Vous pouvez choisir de fournir un modèle de demande, un modèle de réponse ou aucun des deux et AWS AppSync vous les traiterez en conséquence.
Pour en savoir plus sur la charge utile des demandes par défaut et la traduction des réponses AWS AppSync fournies, consultez la référence du [résolveur Direct Lambda](resolver-mapping-template-reference-lambda.md#direct-lambda-resolvers). Pour plus d'informations sur la configuration d'une source de AWS Lambda données et la configuration d'une politique de confiance IAM, voir [Joindre une source de données](attaching-a-data-source.md).
## Configurer des résolveurs Lambda directs
Les sections suivantes vous montrent comment associer des sources de données Lambda et ajouter des résolveurs Lambda à vos champs.
### Ajouter une source de données Lambda
Avant de pouvoir activer les résolveurs Lambda directs, vous devez ajouter une source de données Lambda.
------
#### [ Console ]
1. Connectez-vous à la [AppSyncconsole AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, sélectionnez **Sources de données.**
1. Choisissez **Create data source**.
1. Dans **Nom de la source de données**, entrez un nom pour votre source de données, tel que**myFunction**.
1. Pour **Type de source de données**, sélectionnez **AWS Lambda fonction**.
1. Pour **Région**, choisissez la région appropriée.
1. Pour **Function ARN**, choisissez la fonction Lambda dans la liste déroulante. Vous pouvez rechercher le nom de la fonction ou saisir manuellement l'ARN de la fonction que vous souhaitez utiliser.
1. Créez un nouveau rôle IAM (recommandé) ou choisissez un rôle existant disposant de l'autorisation `lambda:invokeFunction` IAM. Les rôles existants nécessitent une politique de confiance, comme expliqué dans la section [Joindre une source de données](attaching-a-data-source.md).
Voici un exemple de politique IAM disposant des autorisations requises pour effectuer des opérations sur la ressource :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "lambda:invokeFunction" ],
"Resource": [
"arn:aws:lambda:us-west-2:123456789012:function:myFunction",
"arn:aws:lambda:us-west-2:123456789012:function:myFunction:*"
]
}
]
}
```
------
1. Choisissez le bouton **Créer**.
------
#### [ CLI ]
1. Créez un objet de source de données en exécutant la [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-data-source.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-data-source.html)commande.
Vous devez saisir 4 paramètres pour cette commande particulière :
1. Celui `api-id` de votre API.
1. Le `name` de votre source de données. Dans l'exemple de console, il s'agit du **nom de la source de données**.
1. La source `type` de données. Dans l'exemple de console, il s'agit d'**AWS Lambda une fonction**.
1. Le`lambda-config`, qui est l'**ARN de la fonction** dans l'exemple de console.
**Note**
Il existe d'autres paramètres tels `Region` que ceux qui doivent être configurés, mais ils seront généralement définis par défaut sur les valeurs de configuration de votre CLI.
Voici un exemple de commande :
```
aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name myFunction --type AWS_LAMBDA --lambda-config lambdaFunctionArn=arn:aws:lambda:us-west-2:102847592837:function:appsync-lambda-example
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"dataSource": {
"dataSourceArn": "arn:aws:appsync:us-west-2:102847592837:apis/abcdefghijklmnopqrstuvwxyz/datasources/myFunction",
"type": "AWS_LAMBDA",
"name": "myFunction",
"lambdaConfig": {
"lambdaFunctionArn": "arn:aws:lambda:us-west-2:102847592837:function:appsync-lambda-example"
}
}
}
```
1. Pour modifier les attributs d'une source de données, exécutez la [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-data-source.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-data-source.html)commande.
À l'exception du `api-id` paramètre, les paramètres utilisés dans la `create-data-source` commande seront remplacés par les nouvelles valeurs de la `update-data-source` commande.
------
### Activer les résolveurs Lambda directs
Après avoir créé une source de données Lambda et configuré le rôle IAM approprié pour permettre d'invoquer la fonction, vous pouvez la lier AWS AppSync à un résolveur ou à une fonction de pipeline.
------
#### [ Console ]
1. Connectez-vous à la [AppSyncconsole AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Dans la fenêtre **Resolvers**, choisissez un champ ou une opération, puis cliquez sur le bouton **Joindre**.
1. Sur la page **Créer un nouveau résolveur**, choisissez la fonction Lambda dans la liste déroulante.
1. Afin de tirer parti des résolveurs Lambda directs, vérifiez que les modèles de mappage de demandes et de réponses sont désactivés dans la section **Configurer les modèles de mappage**.
1. Cliquez sur le bouton **Enregistrer le résolveur**.
------
#### [ CLI ]
+ Créez un résolveur en exécutant la [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)commande.
Vous devez saisir 6 paramètres pour cette commande particulière :
1. Celui `api-id` de votre API.
1. Le `type-name` type de votre schéma.
1. Le champ `field-name` de votre schéma.
1. Le ou `data-source-name` le nom de votre fonction Lambda.
1. Le`request-mapping-template`, qui est le corps de la demande. Dans l'exemple de console, cela a été désactivé :
```
" "
```
1. Le`response-mapping-template`, qui est le corps de la réponse. Dans l'exemple de console, cela a également été désactivé :
```
" "
```
Voici un exemple de commande :
```
aws appsync create-resolver --api-id abcdefghijklmnopqrstuvwxyz --type-name Subscription --field-name onCreateTodo --data-source-name LambdaTest --request-mapping-template " " --response-mapping-template " "
```
Une sortie sera renvoyée dans la CLI. Voici un exemple :
```
{
"resolver": {
"resolverArn": "arn:aws:appsync:us-west-2:102847592837:apis/abcdefghijklmnopqrstuvwxyz/types/Subscription/resolvers/onCreateTodo",
"typeName": "Subscription",
"kind": "UNIT",
"fieldName": "onCreateTodo",
"dataSourceName": "LambdaTest"
}
}
```
------
Lorsque vous désactivez vos modèles de mappage, plusieurs comportements supplémentaires se produisent dans AWS AppSync :
+ En désactivant un modèle de mappage, vous indiquez AWS AppSync que vous acceptez les traductions de données par défaut spécifiées dans la référence du résolveur Direct [Lambda](resolver-mapping-template-reference-lambda.md#direct-lambda-resolvers).
+ [En désactivant le modèle de mappage des demandes, votre source de données Lambda recevra une charge utile composée de l'ensemble de l'objet Context.](resolver-context-reference.md)
+ En désactivant le modèle de mappage de réponse, le résultat de votre appel Lambda sera traduit en fonction de la version du modèle de mappage de demandes ou si le modèle de mappage de demandes est également désactivé.
# Tester et déboguer des résolveurs dans AWS AppSync (VTL)
**Note**
Nous prenons désormais principalement en charge le runtime APPSYNC\$1JS et sa documentation. [Pensez à utiliser le runtime APPSYNC\$1JS et ses guides ici.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)
AWS AppSync exécute des résolveurs sur un champ GraphQL par rapport à une source de données. Comme décrit dans la section [Présentation du modèle de mappage Resolver](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview), les résolveurs communiquent avec les sources de données à l'aide d'un langage de modélisation. Cela vous permet de personnaliser le comportement et d'appliquer une logique et des conditions avant et après la communication avec la source de données. Pour un guide de programmation de type didacticiel d'introduction à l'écriture de résolveurs, consultez le guide de programmation du modèle de [mappage Resolver](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide).
Pour aider les développeurs à écrire, tester et déboguer ces résolveurs, la AWS AppSync console fournit également des outils permettant de créer une requête et une réponse GraphQL avec des données fictives jusqu'au résolveur de champs individuel. En outre, vous pouvez effectuer des requêtes, des mutations et des abonnements dans la AWS AppSync console et consulter un journal détaillé de l'intégralité CloudWatch de la demande provenant d'Amazon. Cela inclut les résultats d'une source de données.
## Tester avec des données fictives
Lorsqu'un résolveur GraphQL est invoqué, il contient un `context` objet contenant des informations sur la demande. Ces informations incluent les arguments d'un client, les informations d'identité et les données du champ GraphQL parent. Il contient également les résultats de la source de données, qui peuvent être utilisés dans le modèle de réponse. Vous trouverez plus de détails sur cette structure et les utilitaires d'annotations disponibles à utiliser lors de la programmation dans le document [Référence du contexte du modèle de mappage des résolveurs](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference).
Lorsque vous écrivez ou modifiez un résolveur, vous pouvez transmettre un objet de *contexte *fictif* ou de test* dans l'éditeur de console. Cela vous permet de voir comment les deux modèles de la demande et de la réponse évaluent, sans réellement s'exécuter par rapport à une source de données. Par exemple, vous pouvez transmettre un argument de test `firstname: Shaggy` et voir comment il est analysé lors de l'utilisation de `$ctx.args.firstname` dans votre modèle de code. Vous pouvez également tester l'évaluation de n'importe quelle annotation d'utilitaire telle que `$util.autoId()` ou `util.time.nowISO8601()`.
### Tester les résolveurs
Cet exemple utilisera la AWS AppSync console pour tester les résolveurs.
1. Connectez-vous à la [AppSyncconsole AWS Management Console et ouvrez-la](https://console.aws.amazon.com/appsync/).
1. Dans le **APIs tableau de bord**, choisissez votre API GraphQL.
1. Dans la **barre latérale**, choisissez **Schema.**
1. Si ce n'est pas déjà fait, sous le type et à côté du champ, choisissez **Joindre** pour ajouter votre résolveur.
Pour plus d'informations sur la création d'un résolveur complet, voir [Configuration des](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html) résolveurs.
Sinon, sélectionnez le résolveur qui se trouve déjà dans le champ.
1. En haut de la page **Modifier le résolveur**, choisissez **Sélectionner le contexte de test**, puis **Créer un nouveau contexte**.
1. Sélectionnez un exemple d'objet de contexte ou renseignez le JSON manuellement dans la fenêtre de **contexte d'exécution** ci-dessous.
1. Entrez un **nom de contexte de texte**.
1. Choisissez le bouton **Enregistrer**.
1. En haut de la page **Modifier le résolveur**, sélectionnez **Exécuter le test**.
Pour un exemple plus pratique, supposons que vous disposiez d'une application stockant un type GraphQL `Dog` qui utilise la génération automatique d'identifiants pour les objets et les stocke dans Amazon DynamoDB. Il se peut aussi que vous souhaitiez écrire certaines valeurs des arguments d'une mutation GraphQL et permettre uniquement à des utilisateurs spécifiques de voir une réponse. Le schéma pourrait s'apparenter à ce qui suit :
```
type Dog {
breed: String
color: String
}
type Mutation {
addDog(firstname: String, age: Int): Dog
}
```
Lorsque vous ajoutez un résolveur pour la `addDog` mutation, vous pouvez renseigner un objet de contexte comme dans l'exemple suivant. Le suivant possède les arguments `name` et `age` du client, ainsi qu'un `username` renseigné dans l'objet `identity` :
```
{
"arguments" : {
"firstname": "Shaggy",
"age": 4
},
"source" : {},
"result" : {
"breed" : "Miniature Schnauzer",
"color" : "black_grey"
},
"identity": {
"sub" : "uuid",
"issuer" : " https://cognito-idp.{region}.amazonaws.com/{userPoolId}",
"username" : "Nadia",
"claims" : { },
"sourceIp" :[ "x.x.x.x" ],
"defaultAuthStrategy" : "ALLOW"
}
}
```
Vous pouvez effectuer le test en utilisant les modèles de mappage de demande et de réponse suivants :
**Modèle de demande**
```
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"id" : { "S" : "$util.autoId()" }
},
"attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```
**Modèle de réponse**
```
#if ($context.identity.username == "Nadia")
$util.toJson($ctx.result)
#else
$util.unauthorized()
#end
```
Le modèle évalué possède les données de votre objet de contexte du test et la valeur générée à partir de `$util.autoId()`. De plus, si vous deviez modifier `username` avec une valeur autre que `Nadia`, les résultats ne seront pas renvoyés, car le contrôle d'autorisation échouerait. Pour plus d'informations sur le contrôle d'accès détaillé, consultez la section [Cas d'utilisation des autorisations](security-authorization-use-cases.md#aws-appsync-security-authorization-use-cases).
### Tester des modèles de mappage avec AWS AppSync APIs
Vous pouvez utiliser la commande `EvaluateMappingTemplate` API pour tester à distance vos modèles de mappage avec des données simulées. Pour commencer à utiliser la commande, assurez-vous d'avoir ajouté l'`appsync:evaluateMappingTemplate`autorisation à votre politique. Par exemple :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "appsync:evaluateMappingTemplate",
"Resource": "arn:aws:appsync:us-east-1:111122223333:*"
}
]
}
```
------
Vous pouvez utiliser la commande en utilisant le [AWS CLI](https://aws.amazon.com/cli/)ou [AWS SDKs](https://aws.amazon.com/tools/). Prenons par exemple le `Dog` schéma et ses modèles de request/response mappage de la section précédente. À l'aide de la CLI de votre station locale, enregistrez le modèle de demande dans un fichier nommé`request.vtl`, puis enregistrez l'`context`objet dans un fichier nommé`context.json`. Depuis votre shell, exécutez la commande suivante :
```
aws appsync evaluate-mapping-template --template file://request.vtl --context file://context.json
```
Cette commande renvoie la réponse suivante :
```
{
"evaluationResult": "{\n \"version\" : \"2017-02-28\",\n \"operation\" : \"PutItem\",\n \"key\" : {\n \"id\" : { \"S\" : \"afcb4c85-49f8-40de-8f2b-248949176456\" }\n },\n \"attributeValues\" : {\"firstname\":{\"S\":\"Shaggy\"},\"age\":{\"N\":4}}\n}\n"
}
```
`evaluationResult`Il contient les résultats du test de votre modèle fourni avec le modèle fourni`context`. Vous pouvez également tester vos modèles à l'aide du AWS SDKs. Voici un exemple d'utilisation du AWS SDK pour la JavaScript version 2 :
```
const AWS = require('aws-sdk')
const client = new AWS.AppSync({ region: 'us-east-2' })
const template = fs.readFileSync('./request.vtl', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')
client
.evaluateMappingTemplate({ template, context })
.promise()
.then((data) => console.log(data))
```
À l'aide du SDK, vous pouvez facilement intégrer les tests de votre suite de tests préférée pour valider le comportement de votre modèle. Nous vous recommandons de créer des tests à l'aide du [Jest Testing Framework](https://jestjs.io/), mais toutes les suites de tests fonctionnent. L'extrait suivant montre une exécution de validation hypothétique. Notez que nous nous attendons à ce que la réponse d'évaluation soit un JSON valide. Nous utilisons donc `JSON.parse` pour récupérer le JSON à partir de la réponse sous forme de chaîne :
```
const AWS = require('aws-sdk')
const fs = require('fs')
const client = new AWS.AppSync({ region: 'us-east-2' })
test('request correctly calls DynamoDB', async () => {
const template = fs.readFileSync('./request.vtl', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')
const contextJSON = JSON.parse(context)
const response = await client.evaluateMappingTemplate({ template, context }).promise()
const result = JSON.parse(response.evaluationResult)
expect(result.key.id.S).toBeDefined()
expect(result.attributeValues.firstname.S).toEqual(contextJSON.arguments.firstname)
})
```
Cela donne le résultat suivant :
```
Ran all test suites.
> jest
PASS ./index.test.js
✓ request correctly calls DynamoDB (543 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 1.511 s, estimated 2 s
```
## Débogage d'une requête en direct
Rien ne remplace un end-to-end test et une journalisation pour déboguer une application de production. AWS AppSync vous permet de consigner les erreurs et de fournir les détails complets des demandes à l'aide d'Amazon CloudWatch. En outre, vous pouvez utiliser la AWS AppSync console pour tester les requêtes GraphQL, les mutations et les abonnements, ainsi que pour diffuser en direct les données du journal de chaque requête dans l'éditeur de requêtes afin de les déboguer en temps réel. Pour les abonnements, les journaux affichent les informations de temps de connexion.
Pour ce faire, vous devez activer Amazon CloudWatch Logs à l'avance, comme décrit dans [Surveillance et journalisation](monitoring.md#aws-appsync-monitoring). Ensuite, dans la AWS AppSync console, choisissez l'onglet **Requêtes**, puis entrez une requête GraphQL valide. Dans la section inférieure droite, cliquez et faites glisser la fenêtre **Logs** pour ouvrir la vue des logs. À l'aide de la flèche « Play » en haut de la page, exécutez votre requête GraphQL. Dans quelques instants, vos journaux complets de demande et de réponse pour l'opération sont diffusés vers cette section et vous pouvez les voir dans la console.
# Configuration et utilisation de résolveurs de pipeline dans AWS AppSync (VTL)
**Note**
Nous prenons désormais principalement en charge le runtime APPSYNC\$1JS et sa documentation. [Pensez à utiliser le runtime APPSYNC\$1JS et ses guides ici.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)
AWS AppSync exécute des résolveurs sur un champ GraphQL. Dans certains cas, les applications nécessitent l'exécution de plusieurs opérations pour résoudre un seul champ GraphQL. Avec les résolveurs de pipeline, les développeurs peuvent désormais composer des opérations appelées fonctions et les exécuter en séquence. Les résolveurs de pipeline sont utiles pour les applications qui, par exemple, doivent effectuer un contrôle d'autorisation avant d'extraire des données pour un champ.
Un résolveur de pipeline est composé d'un modèle de mappage **Avant**, d'un modèle de mappage **Après** et d'une liste de Fonctions. Chaque fonction possède un modèle de mappage de **requêtes** et de **réponses** qu'elle exécute par rapport à une source de données. Comme un résolveur de pipeline délègue l'exécution à une liste de fonctions, il n'est lié à aucune source de données. Les résolveurs d'unités et les fonctions sont des primitives qui exécutent des opérations sur des sources de données. Consultez la [présentation du modèle de mappage Resolver](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview) pour plus d'informations.
## Étape 1 : Création d'un résolveur de pipeline
Dans la AWS AppSync console, accédez à la page **Schéma**.
Enregistrez le schéma suivant :
```
schema {
query: Query
mutation: Mutation
}
type Mutation {
signUp(input: Signup): User
}
type Query {
getUser(id: ID!): User
}
input Signup {
username: String!
email: String!
}
type User {
id: ID!
username: String
email: AWSEmail
}
```
Nous allons raccorder un résolveur de pipeline au champ **signUp** sur le type **Mutation**. Dans le champ Type de **mutation** sur le côté droit, choisissez **Attacher** à côté du champ de `signUp` mutation. Sur la page de création d'un résolveur, cliquez sur **Actions**, puis sur **Mettre à jour le moteur d'exécution**. Choisissez`Pipeline Resolver`, puis choisissez`VTL`, puis choisissez **Mettre à jour**. La page doit désormais afficher trois sections : une zone de texte **avant le mappage du modèle**, une section **Fonctions** et une zone de texte **après le mappage du modèle**.
Notre résolveur de pipeline inscrit un utilisateur en validant tout d'abord l'adresse e-mail saisie, puis en enregistrant l'utilisateur dans le système. Nous allons encapsuler la validation d'e-mail dans une fonction **validateEmail** et l'enregistrement de l'utilisateur dans une fonction **saveUser**. La fonction **validateEmail** s'exécute d'abord, puis si l'e-mail est valide, alors la fonction **saveUser** s'exécute.
Le flux d'exécution sera comme suit :
1. Modèle de mappage de demande de résolveur Mutation.signUp
1. Fonction validateEmail
1. Fonction saveUser
1. Modèle de mappage de réponse de résolveur Mutation.signUp
Comme nous réutiliserons probablement la fonction **ValidateEmail** dans d'autres résolveurs de notre API, nous voulons éviter d'`$ctx.args`y accéder car ceux-ci changeront d'un champ GraphQL à l'autre. Au lieu de cela, nous pouvons utiliser le `$ctx.stash` pour stocker l'attribut e-mail depuis l'argument de champ de saisie `signUp(input: Signup)`.
Modèle **de** mappage BEFORE :
```
## store email input field into a generic email key
$util.qr($ctx.stash.put("email", $ctx.args.input.email))
{}
```
La console fournit un modèle de mappage **AFTER** passthrough par défaut que nous utiliserons :
```
$util.toJson($ctx.result)
```
Choisissez **Créer** ou **Enregistrer** pour mettre à jour le résolveur.
## Étape 2 : Création d'une fonction
Sur la page du résolveur de pipeline, dans la section **Fonctions**, cliquez sur **Ajouter une fonction**, puis sur **Créer une nouvelle fonction**. Il est également possible de créer des fonctions sans passer par la page du résolveur ; pour cela, dans la AWS AppSync console, rendez-vous sur la page **Fonctions**. Choisissez le bouton **Créer une fonction**. Créons une fonction permettant de vérifier si un e-mail est valide et provient d'un domaine spécifique. Si l'e-mail n'est pas valide, la fonction renvoie une erreur. Dans le cas contraire, elle transmet les données saisies.
Sur la page des nouvelles fonctions, choisissez **Actions**, puis **Mettre à jour le moteur d'exécution**. Choisissez`VTL`, puis **Mettre à jour**. Assurez-vous d'avoir créé une source de données de type **NONE**. Choisissez cette source de données dans la liste des **noms des sources de données**. Pour le **nom de la fonction**, entrez`validateEmail`. Dans la zone du **code de fonction**, remplacez tout par cet extrait de code :
```
#set($valid = $util.matches("^[a-zA-Z0-9_.+-]+@(?:(?:[a-zA-Z0-9-]+\.)?[a-zA-Z]+\.)?(myvaliddomain)\.com", $ctx.stash.email))
#if (!$valid)
$util.error("$ctx.stash.email is not a valid email.")
#end
{
"payload": { "email": $util.toJson(${ctx.stash.email}) }
}
```
Collez ceci dans le modèle de mappage des réponses :
```
$util.toJson($ctx.result)
```
Passez en revue vos modifications, puis choisissez **Créer**. Nous venons de créer notre fonction **validateEmail**. Répétez ces étapes pour créer la fonction **SaveUser** avec les modèles de mappage de demandes et de réponses suivants (par souci de simplicité, nous utilisons **une** source de données NONE et prétendons que l'utilisateur a été enregistré dans le système après l'exécution de la fonction. ) :
Modèle de mappage de demande :
```
## $ctx.prev.result contains the signup input values. We could have also
## used $ctx.args.input.
{
"payload": $util.toJson($ctx.prev.result)
}
```
Modèle de mappage de réponse :
```
## an id is required so let's add a unique random identifier to the output
$util.qr($ctx.result.put("id", $util.autoId()))
$util.toJson($ctx.result)
```
Nous venons de créer notre fonction **SaveUser**.
## Étape 3 : Ajouter une fonction à un résolveur de pipeline
Nos fonctions auraient dû être ajoutées automatiquement au résolveur de pipeline que nous venons de créer. Si ce n'était pas le cas, ou si vous avez créé les fonctions via la page **Fonctions**, vous pouvez cliquer sur **Ajouter une fonction** sur la page du résolveur pour les joindre. Ajoutez les fonctions **ValidateEmail** **et** SaveUser au résolveur. La fonction **validateEmail** doit être placée avant la fonction **saveUser**. Au fur et à mesure que vous ajoutez des fonctions, vous pouvez utiliser les options de **déplacement vers le haut** **et de déplacement vers le bas** pour réorganiser l'ordre d'exécution de vos fonctions. Passez en revue vos modifications, puis choisissez **Enregistrer**.
## Étape 4 : Exécution d'une requête
Dans la AWS AppSync console, accédez à la page **Requêtes**. Dans l'explorateur, assurez-vous d'utiliser votre mutation. Si ce n'est pas le cas, choisissez `Mutation` dans la liste déroulante, puis choisissez`+`. Entrez la requête suivante :
```
mutation {
signUp(input: {
email: "nadia@myvaliddomain.com"
username: "nadia"
}) {
id
email
}
}
```
Cela devrait renvoyer quelque chose comme :
```
{
"data": {
"signUp": {
"id": "256b6cc2-4694-46f4-a55e-8cb14cc5d7fc",
"email": "nadia@myvaliddomain.com"
}
}
}
```
Nous avons inscrit notre utilisateur et validé l'e-mail saisi à l'aide d'un résolveur de pipeline. Pour suivre un didacticiel plus complet sur les résolveurs de pipeline, vous pouvez consulter le [Didacticiel : Résolveurs de Pipeline](tutorial-pipeline-resolvers.md#aws-appsync-tutorial-pipeline-resolvers)