Tutoriel : Utilisation AWS AppSync pour créer des AWS Lambda résolveurs

Note

Nous prenons désormais principalement en charge le runtime APPSYNC _JS et sa documentation. Pensez à utiliser le runtime APPSYNC _JS et ses guides ici.

Vous pouvez utiliser AWS Lambda with AWS AppSync pour résoudre n'importe quel champ GraphQL. Par exemple, une requête GraphQL peut envoyer un appel à une instance Amazon Relational Database Service (AmazonRDS), et une mutation GraphQL peut écrire dans un flux Amazon Kinesis. Dans cette section, nous allons vous montrer comment écrire une fonction Lambda qui exécute une logique métier basée sur l'invocation d'une opération de terrain GraphQL.

Création d’une fonction Lambda

L'exemple suivant montre une fonction Lambda écrite Node.js qui effectue différentes opérations sur des articles de blog dans le cadre d'une application de publication de blog.

exports.handler = (event, context, callback) => {
    console.log("Received event {}", JSON.stringify(event, 3));
    var posts = {
         "1": {"id": "1", "title": "First book", "author": "Author1", "url": "https://amazon.com/", "content": "SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1", "ups": "100", "downs": "10"},
         "2": {"id": "2", "title": "Second book", "author": "Author2", "url": "https://amazon.com", "content": "SAMPLE TEXT AUTHOR 2 SAMPLE TEXT AUTHOR 2 SAMPLE TEXT", "ups": "100", "downs": "10"},
         "3": {"id": "3", "title": "Third book", "author": "Author3", "url": null, "content": null, "ups": null, "downs": null },
         "4": {"id": "4", "title": "Fourth book", "author": "Author4", "url": "https://www.amazon.com/", "content": "SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4", "ups": "1000", "downs": "0"},
         "5": {"id": "5", "title": "Fifth book", "author": "Author5", "url": "https://www.amazon.com/", "content": "SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT", "ups": "50", "downs": "0"} };

    var relatedPosts = {
        "1": [posts['4']],
        "2": [posts['3'], posts['5']],
        "3": [posts['2'], posts['1']],
        "4": [posts['2'], posts['1']],
        "5": []
    };

    console.log("Got an Invoke Request.");
    switch(event.field) {
        case "getPost":
            var id = event.arguments.id;
            callback(null, posts[id]);
            break;
        case "allPosts":
            var values = [];
            for(var d in posts){
                values.push(posts[d]);
            }
            callback(null, values);
            break;
        case "addPost":
            // return the arguments back
            callback(null, event.arguments);
            break;
        case "addPostErrorWithData":
            var id = event.arguments.id;
            var result = posts[id];
            // attached additional error information to the post
            result.errorMessage = 'Error with the mutation, data has changed';
            result.errorType = 'MUTATION_ERROR';
            callback(null, result);
            break;
        case "relatedPosts":
            var id = event.source.id;
            callback(null, relatedPosts[id]);
            break;
        default:
            callback("Unknown field, unable to resolve" + event.field, null);
            break;
    }
};

Cette fonction Lambda récupère une publication par identifiant, ajoute une publication, récupère une liste de publications et récupère les publications associées à une publication donnée.

Remarque : La fonction Lambda utilise l'switchinstruction on event.field pour déterminer le champ en cours de résolution.

Créez cette fonction Lambda à l'aide de la console de AWS gestion ou d'une AWS CloudFormation pile. Pour créer la fonction à partir d'une CloudFormation pile, vous pouvez utiliser la commande suivante AWS Command Line Interface (AWS CLI) :

aws cloudformation create-stack --stack-name AppSyncLambdaExample \
--template-url https://s3.us-west-2.amazonaws.com/awsappsync/resources/lambda/LambdaCFTemplate.yaml \
--capabilities CAPABILITY_NAMED_IAM

Vous pouvez également lancer le AWS CloudFormation stack dans la AWS région ouest des États-Unis (Oregon) sur votre AWS compte à partir d'ici :

Configuration d'une source de données pour Lambda

Après avoir créé la fonction Lambda, accédez à votre GraphQL API dans la AWS AppSync console, puis choisissez l'onglet Sources de données.

Choisissez Créer une source de données, entrez un nom de source de données convivial (par exemple,Lambda), puis pour Type de source de données, choisissez AWS Lambda fonction. Pour Région, choisissez la même région que votre fonction. (Si vous avez créé la fonction à partir de la CloudFormation pile fournie, elle est probablement en US- WEST -2.) Pour Function ARN, choisissez le nom de ressource Amazon (ARN) de votre fonction Lambda.

Après avoir choisi votre fonction Lambda, vous pouvez soit créer un nouveau rôle AWS Identity and Access Management (IAM) (pour lequel les autorisations appropriées AWS AppSync sont attribuées), soit choisir un rôle existant doté de la politique intégrée suivante :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": "arn:aws:lambda:REGION:ACCOUNTNUMBER:function/LAMBDA_FUNCTION"
        }
    ]
}

Vous devez également établir une relation de confiance avec AWS AppSync le IAM rôle comme suit :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "appsync.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Création d'un schéma GraphQL

Maintenant que la source de données est connectée à votre fonction Lambda, créez un schéma GraphQL.

Dans l'éditeur de schéma de la AWS AppSync console, assurez-vous que votre schéma correspond au schéma suivant :

schema {
    query: Query
    mutation: Mutation
}

type Query {
    getPost(id:ID!): Post
    allPosts: [Post]
}

type Mutation {
    addPost(id: ID!, author: String!, title: String, content: String, url: String): Post!
}

type Post {
    id: ID!
    author: String!
    title: String
    content: String
    url: String
    ups: Int
    downs: Int
    relatedPosts: [Post]
}

Configuration des résolveurs

Maintenant que vous avez enregistré une source de données Lambda et un schéma GraphQL valide, vous pouvez connecter vos champs GraphQL à votre source de données Lambda à l'aide de résolveurs.

Pour créer un résolveur, vous aurez besoin de modèles de mappage. Pour en savoir plus sur les modèles de mappage, consultezResolver Mapping Template Overview.

Pour plus d'informations sur les modèles de mappage Lambda, consultez. Resolver mapping template reference for Lambda

Au cours de cette étape, vous associez un résolveur à la fonction Lambda pour les champs suivants getPost(id:ID!): Post :allPosts: [Post],addPost(id: ID!, author: String!, title: String, content: String, url: String): Post!, et. Post.relatedPosts: [Post]

Dans l'éditeur de schéma de la AWS AppSync console, sur le côté droit, choisissez Attach Resolver forgetPost(id:ID!): Post.

Ensuite, dans le menu Action, choisissez Update runtime, puis Unit Resolver (VTLuniquement).

Ensuite, choisissez votre source de données Lambda. Dans la section modèle de mappage de demande, choisissez Invoquer et transférer des arguments.

Modifiez l'objet payload pour ajouter le nom du champ. Votre modèle doit ressembler au suivant :

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "getPost",
        "arguments":  $utils.toJson($context.arguments)
    }
}

Dans la section modèle de mappage de réponse section, choisissez Renvoyer le résultat de Lambda.

Dans ce cas, utilisez le modèle de base en l'état. Il devrait se présenter comme suit :

$utils.toJson($context.result)

Choisissez Enregistrer. Vous avez joint votre première résolveur avec succès. Répétez cette opération pour les autres champs comme suit :

Pour le modèle de mappage de demande addPost(id: ID!, author: String!, title: String, content: String, url: String): Post! :

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "addPost",
        "arguments":  $utils.toJson($context.arguments)
    }
}

Pour le modèle de mappage de réponse addPost(id: ID!, author: String!, title: String, content: String, url: String): Post! :

$utils.toJson($context.result)

Pour le modèle de mappage de demande allPosts: [Post] :

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "allPosts"
    }
}

Pour le modèle de mappage de réponse allPosts: [Post] :

$utils.toJson($context.result)

Pour le modèle de mappage de demande Post.relatedPosts: [Post] :

{
    "version": "2017-02-28",
    "operation": "Invoke",
    "payload": {
        "field": "relatedPosts",
        "source":  $utils.toJson($context.source)
    }
}

Pour le modèle de mappage de réponse Post.relatedPosts: [Post] :

$utils.toJson($context.result)

Testez votre GraphQL API

Maintenant que votre fonction Lambda est connectée aux résolveurs GraphQL, vous pouvez exécuter des mutations et des requêtes à l'aide de la console ou d'une application cliente.

Sur le côté gauche de la AWS AppSync console, choisissez Requêtes, puis collez le code suivant :

addPost Mutation

mutation addPost {
    addPost(
        id: 6
        author: "Author6"
        title: "Sixth book"
        url: "https://www.amazon.com/"
        content: "This is the book is a tutorial for using GraphQL with AWS AppSync."
    ) {
        id
        author
        title
        content
        url
        ups
        downs
    }
}

getPost Requête

query getPost {
    getPost(id: "2") {
        id
        author
        title
        content
        url
        ups
        downs
    }
}

allPosts Requête

query allPosts {
    allPosts {
        id
        author
        title
        content
        url
        ups
        downs
        relatedPosts {
            id
            title
        }
    }
}

Erreurs de renvoi

Toute résolution de champ donnée peut entraîner une erreur. Avec AWS AppSync, vous pouvez générer des erreurs provenant des sources suivantes :

• Modèle de mappage de demande ou de réponse

• Fonction Lambda

À partir du modèle de mappage

Pour signaler des erreurs intentionnelles, vous pouvez utiliser la méthode d'$utils.errorassistance du modèle Velocity Template Language (VTL). Elle prend comme un argument un errorMessage, un errorType et une valeur data facultative. L'objet data est utile pour renvoyer des données supplémentaires au client, lorsqu'une erreur a été déclenchée. L'objet data sera ajouté à errors dans la réponse GraphQL finale.

L'exemple suivant montre comment utiliser le modèle de mappage de réponse dans le Post.relatedPosts: [Post] :

$utils.error("Failed to fetch relatedPosts", "LambdaFailure", $context.result)

Cela génère une réponse GraphQL similaire à ce qui suit :

{
    "data": {
        "allPosts": [
            {
                "id": "2",
                "title": "Second book",
                "relatedPosts": null
            },
            ...
        ]
    },
    "errors": [
        {
            "path": [
                "allPosts",
                0,
                "relatedPosts"
            ],
            "errorType": "LambdaFailure",
            "locations": [
                {
                    "line": 5,
                    "column": 5
                }
            ],
            "message": "Failed to fetch relatedPosts",
            "data": [
                {
                  "id": "2",
                  "title": "Second book"
                },
                {
                  "id": "1",
                  "title": "First book"
                }
            ]
        }
    ]
}

où allPosts[0].relatedPosts est null du fait de l'erreur et errorMessage, errorType et data sont présents dans l'objet data.errors[0].

À partir de la fonction Lambda

AWS AppSync comprend également les erreurs générées par la fonction Lambda. Le modèle de programmation Lambda vous permet de signaler les erreurs gérées. Si la fonction Lambda génère une erreur, elle AWS AppSync ne parvient pas à résoudre le champ actuel. Seul le message d'erreur renvoyé par Lambda est défini dans la réponse. Actuellement, vous ne pouvez pas renvoyer de données superflues au client en déclenchant une erreur à partir de la fonction Lambda.

Remarque : Si votre fonction Lambda génère une erreur non gérée, AWS AppSync utilise le message d'erreur défini par Lambda.

La fonction Lambda suivante génère une erreur :

exports.handler = (event, context, callback) => {
    console.log("Received event {}", JSON.stringify(event, 3));
    callback("I fail. Always.");
};

Cela renvoie une réponse GraphQL similaire à ce qui suit :

{
    "data": {
        "allPosts": [
            {
                "id": "2",
                "title": "Second book",
                "relatedPosts": null
            },
            ...
        ]
    },
    "errors": [
        {
            "path": [
                "allPosts",
                0,
                "relatedPosts"
            ],
            "errorType": "Lambda:Handled",
            "locations": [
                {
                    "line": 5,
                    "column": 5
                }
            ],
            "message": "I fail. Always."
        }
    ]
}

Cas d'utilisation avancé : traitement par lots

Dans cet exemple, la fonction Lambda possède un relatedPosts champ qui renvoie une liste de publications connexes pour une publication donnée. Dans les exemples de requêtes, l'invocation du allPosts champ par la fonction Lambda renvoie cinq messages. Comme nous avons précisé que nous voulions également résoudre le problème relatedPosts pour chaque message renvoyé, l'opération de relatedPosts terrain est invoquée cinq fois.

query allPosts {
    allPosts {   // 1 Lambda invocation - yields 5 Posts
        id
        author
        title
        content
        url
        ups
        downs
        relatedPosts {   // 5 Lambda invocations - each yields 5 posts
            id
            title
        }
    }
}

Bien que cela ne semble pas important dans cet exemple spécifique, ce surchargement aggravé peut rapidement saper l'application.

Si vous souhaitez à nouveau extraire relatedPosts sur le Posts associé renvoyé dans la même requête, le nombre d'appels augmenterait considérablement.

query allPosts {
    allPosts {   // 1 Lambda invocation - yields 5 Posts
        id
        author
        title
        content
        url
        ups
        downs
        relatedPosts {   // 5 Lambda invocations - each yield 5 posts = 5 x 5 Posts
            id
            title
            relatedPosts {  // 5 x 5 Lambda invocations - each yield 5 posts = 25 x 5 Posts
                id
                title
                author
            }
        }
    }
}

Dans cette requête relativement simple, AWS AppSync invoquerait la fonction Lambda 1 + 5 + 25 = 31 fois.

Il s'agit d'un défi assez courant, souvent appelé « problème N+1 » (dans ce cas, N = 5) et qui peut entraîner une augmentation de la latence et des coûts de l'application.

L'une des approches possibles pour résoudre ce problème est de regrouper les demandes de résolveur de champ similaires. Dans cet exemple, au lieu de demander à la fonction Lambda de résoudre une liste de publications connexes pour une publication donnée, elle pourrait résoudre une liste de publications connexes pour un lot de publications donné.

Pour démontrer cela, nous allons passer le résolveur Post.relatedPosts: [Post] à un résolveur capable d'effectuer des traitements par lots.

Sur le côté droit de la AWS AppSync console, choisissez le Post.relatedPosts: [Post] résolveur existant. Modifiez le modèle de mappage de demande comme suit :

{
    "version": "2017-02-28",
    "operation": "BatchInvoke",
    "payload": {
        "field": "relatedPosts",
        "source":  $utils.toJson($context.source)
    }
}

Seul le champ operation est passé de Invoke à BatchInvoke. Le champ de charge utile devient désormais un tableau de tout ce qui est spécifié dans le modèle. Dans cet exemple, la fonction Lambda reçoit les informations suivantes en entrée :

[
    {
        "field": "relatedPosts",
        "source": {
            "id": 1
        }
    },
    {
        "field": "relatedPosts",
        "source": {
            "id": 2
        }
    },
    ...
]

Lorsqu'elle BatchInvoke est spécifiée dans le modèle de mappage des demandes, la fonction Lambda reçoit une liste de demandes et renvoie une liste de résultats.

Plus précisément, la liste des résultats doit correspondre à la taille et à l'ordre des entrées de charge utile de la demande afin de AWS AppSync pouvoir correspondre aux résultats en conséquence.

Dans cet exemple de traitement par lots, la fonction Lambda renvoie un lot de résultats comme suit :

[
    [{"id":"2","title":"Second book"}, {"id":"3","title":"Third book"}],   // relatedPosts for id=1
    [{"id":"3","title":"Third book"}]                                                             // relatedPosts for id=2
]

La fonction Lambda suivante dans Node.js illustre cette fonctionnalité de traitement par lots pour le Post.relatedPosts champ comme suit :

exports.handler = (event, context, callback) => {
    console.log("Received event {}", JSON.stringify(event, 3));
    var posts = {
         "1": {"id": "1", "title": "First book", "author": "Author1", "url": "https://amazon.com/", "content": "SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1", "ups": "100", "downs": "10"},
         "2": {"id": "2", "title": "Second book", "author": "Author2", "url": "https://amazon.com", "content": "SAMPLE TEXT AUTHOR 2 SAMPLE TEXT AUTHOR 2 SAMPLE TEXT", "ups": "100", "downs": "10"},
         "3": {"id": "3", "title": "Third book", "author": "Author3", "url": null, "content": null, "ups": null, "downs": null },
         "4": {"id": "4", "title": "Fourth book", "author": "Author4", "url": "https://www.amazon.com/", "content": "SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4", "ups": "1000", "downs": "0"},
         "5": {"id": "5", "title": "Fifth book", "author": "Author5", "url": "https://www.amazon.com/", "content": "SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT", "ups": "50", "downs": "0"} };

    var relatedPosts = {
        "1": [posts['4']],
        "2": [posts['3'], posts['5']],
        "3": [posts['2'], posts['1']],
        "4": [posts['2'], posts['1']],
        "5": []
    };

    console.log("Got a BatchInvoke Request. The payload has %d items to resolve.", event.length);
    // event is now an array
    var field = event[0].field;
    switch(field) {
        case "relatedPosts":
            var results = [];
            // the response MUST contain the same number
            // of entries as the payload array
            for (var i=0; i< event.length; i++) {
                console.log("post {}", JSON.stringify(event[i].source));
                results.push(relatedPosts[event[i].source.id]);
            }
            console.log("results {}", JSON.stringify(results));
            callback(null, results);
            break;
        default:
            callback("Unknown field, unable to resolve" + field, null);
            break;
    }
};

Renvoi d'erreurs individuelles

Les exemples précédents montrent qu'il est possible de renvoyer une seule erreur à partir de la fonction Lambda ou de générer une erreur à partir des modèles de mappage. Pour les appels par lots, le fait de générer une erreur à partir de la fonction Lambda indique qu'un lot entier a échoué. Cela peut être acceptable pour des scénarios spécifiques dans lesquels une erreur irrécupérable se produit, telle qu'un échec de connexion à un magasin de données. Toutefois, dans les cas où certains éléments du lot réussissent et d'autres échouent, il est possible de renvoyer à la fois des erreurs et des données valides. Étant donné que la réponse par lots AWS AppSync nécessite de répertorier les éléments correspondant à la taille d'origine du lot, vous devez définir une structure de données capable de différencier les données valides d'une erreur.

Par exemple, si la fonction Lambda est censée renvoyer un lot de publications connexes, vous pouvez choisir de renvoyer une liste d'Responseobjets contenant des données et errorTypedes champs facultatifs pour chaque objet. errorMessage Si le errorMessagechamp est présent, cela signifie qu'une erreur s'est produite.

Le code suivant montre comment mettre à jour la fonction Lambda :

exports.handler = (event, context, callback) => {
    console.log("Received event {}", JSON.stringify(event, 3));
    var posts = {
         "1": {"id": "1", "title": "First book", "author": "Author1", "url": "https://amazon.com/", "content": "SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1 SAMPLE TEXT AUTHOR 1", "ups": "100", "downs": "10"},
         "2": {"id": "2", "title": "Second book", "author": "Author2", "url": "https://amazon.com", "content": "SAMPLE TEXT AUTHOR 2 SAMPLE TEXT AUTHOR 2 SAMPLE TEXT", "ups": "100", "downs": "10"},
         "3": {"id": "3", "title": "Third book", "author": "Author3", "url": null, "content": null, "ups": null, "downs": null },
         "4": {"id": "4", "title": "Fourth book", "author": "Author4", "url": "https://www.amazon.com/", "content": "SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4 SAMPLE TEXT AUTHOR 4", "ups": "1000", "downs": "0"},
         "5": {"id": "5", "title": "Fifth book", "author": "Author5", "url": "https://www.amazon.com/", "content": "SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT AUTHOR 5 SAMPLE TEXT", "ups": "50", "downs": "0"} };

    var relatedPosts = {
        "1": [posts['4']],
        "2": [posts['3'], posts['5']],
        "3": [posts['2'], posts['1']],
        "4": [posts['2'], posts['1']],
        "5": []
    };

    console.log("Got a BatchInvoke Request. The payload has %d items to resolve.", event.length);
    // event is now an array
    var field = event[0].field;
    switch(field) {
        case "relatedPosts":
            var results = [];
            results.push({ 'data': relatedPosts['1'] });
            results.push({ 'data': relatedPosts['2'] });
            results.push({ 'data': null, 'errorMessage': 'Error Happened', 'errorType': 'ERROR' });
            results.push(null);
            results.push({ 'data': relatedPosts['3'], 'errorMessage': 'Error Happened with last result', 'errorType': 'ERROR' });
            callback(null, results);
            break;
        default:
            callback("Unknown field, unable to resolve" + field, null);
            break;
    }
};

Dans cet exemple, le modèle de mappage des réponses suivant analyse chaque élément de la fonction Lambda et signale les erreurs éventuelles :

#if( $context.result && $context.result.errorMessage )
    $utils.error($context.result.errorMessage, $context.result.errorType, $context.result.data)
#else
    $utils.toJson($context.result.data)
#end

Cet exemple renvoie une réponse GraphQL similaire à ce qui suit :

{
  "data": {
    "allPosts": [
      {
        "id": "1",
        "relatedPostsPartialErrors": [
          {
            "id": "4",
            "title": "Fourth book"
          }
        ]
      },
      {
        "id": "2",
        "relatedPostsPartialErrors": [
          {
            "id": "3",
            "title": "Third book"
          },
          {
            "id": "5",
            "title": "Fifth book"
          }
        ]
      },
      {
        "id": "3",
        "relatedPostsPartialErrors": null
      },
      {
        "id": "4",
        "relatedPostsPartialErrors": null
      },
      {
        "id": "5",
        "relatedPostsPartialErrors": null
      }
    ]
  },
  "errors": [
    {
      "path": [
        "allPosts",
        2,
        "relatedPostsPartialErrors"
      ],
      "errorType": "ERROR",
      "locations": [
        {
          "line": 4,
          "column": 9
        }
      ],
      "message": "Error Happened"
    },
    {
      "path": [
        "allPosts",
        4,
        "relatedPostsPartialErrors"
      ],
      "data": [
        {
          "id": "2",
          "title": "Second book"
        },
        {
          "id": "1",
          "title": "First book"
        }
      ],
      "errorType": "ERROR",
      "locations": [
        {
          "line": 4,
          "column": 9
        }
      ],
      "message": "Error Happened with last result"
    }
  ]
}

Configuration de la taille de lot maximale

Par défaut, lors de l'utilisationBatchInvoke, AWS AppSync envoie des requêtes à votre fonction Lambda par lots de cinq éléments maximum. Vous pouvez configurer la taille de lot maximale de vos résolveurs Lambda.

Pour configurer la taille de lot maximale sur un résolveur, utilisez la commande suivante dans le AWS Command Line Interface ()AWS CLI :

$ aws appsync create-resolver --api-id <api-id> --type-name Query --field-name relatedPosts \
 --request-mapping-template "<template>" --response-mapping-template "<template>" --data-source-name "<lambda-datasource>" \ 
 --max-batch-size X

Note

Lorsque vous fournissez un modèle de mappage de demandes, vous devez utiliser l'BatchInvokeopération pour utiliser le traitement par lots.

Vous pouvez également utiliser la commande suivante pour activer et configurer le traitement par lots sur les résolveurs Lambda directs :

$ aws appsync create-resolver --api-id <api-id> --type-name Query --field-name relatedPosts \
 --data-source-name "<lambda-datasource>" \ 
 --max-batch-size X

Configuration de la taille de lot maximale avec des modèles VTL

Pour les résolveurs Lambda dotés de modèles VTL intégrés à la demande, la taille de lot maximale n'aura aucun effet à moins qu'ils ne l'aient directement spécifiée en tant qu'opération dans. BatchInvoke VTL De même, si vous effectuez une mutation de haut niveau, le traitement par lots n'est pas effectué pour les mutations car la spécification GraphQL exige que les mutations parallèles soient exécutées de manière séquentielle.

Par exemple, prenons les mutations suivantes :

type Mutation {
    putItem(input: Item): Item
    putItems(inputs: [Item]): [Item]
}

En utilisant la première mutation, nous pouvons créer 10 Items comme indiqué dans l'extrait ci-dessous :

mutation MyMutation {
    v1: putItem($someItem1) {
        id,
        name
    }
    v2: putItem($someItem2) {
        id,
        name
    }
    v3: putItem($someItem3) {
        id,
        name
    } 
    v4: putItem($someItem4) {
        id,
        name
    }
    v5: putItem($someItem5) {
        id,
        name
    }
    v6: putItem($someItem6) {
        id,
        name
    } 
    v7: putItem($someItem7) {
        id,
        name
    }
    v8: putItem($someItem8) {
        id,
        name
    }
    v9: putItem($someItem9) {
        id,
        name
    }
    v10: putItem($someItem10) {
        id,
        name
    }
}

Dans cet exemple, le ne Items sera pas regroupé par lots de 10, même si la taille de lot maximale est définie sur 10 dans le résolveur Lambda. Ils s'exécuteront plutôt de manière séquentielle conformément à la spécification GraphQL.

Pour effectuer une véritable mutation par lots, vous pouvez suivre l'exemple ci-dessous en utilisant la deuxième mutation :

mutation MyMutation {
    putItems([$someItem1, $someItem2, $someItem3,$someItem4, $someItem5, $someItem6, 
    $someItem7, $someItem8, $someItem9, $someItem10]) {
    id,
    name
    }
}

Pour plus d'informations sur l'utilisation du traitement par lots avec les résolveurs Lambda directs, consultez. Résolveurs Lambda directs