Étape 2 : Joindre une source de données dans AWS AppSync - AWS AppSync
Types de sources de donnéesAjouter une source de données

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.

Étape 2 : Joindre une source de données dans AWS AppSync

Les sources de données sont des ressources de votre AWS compte avec lesquelles GraphQL APIs peut interagir. AWS AppSync prend en charge une multitude de sources de données telles qu'Amazon DynamoDB AWS Lambda, les bases de données relationnelles (Amazon Aurora Serverless), Amazon OpenSearch Service et les points de terminaison. HTTP An AWS AppSync API peut être configuré pour interagir avec plusieurs sources de données, ce qui vous permet d'agréger les données en un seul endroit. AWS AppSync peut utiliser les AWS ressources existantes de votre compte ou approvisionner des tables DynamoDB en votre nom à partir d'une définition de schéma.

La section suivante explique comment associer une source de données à votre GraphQLAPI.

Types de sources de données

Maintenant que vous avez créé un schéma dans la AWS AppSync console, vous pouvez y associer une source de données. Lorsque vous créez une table Amazon DynamoDB pour la première foisAPI, il est possible de configurer une table Amazon DynamoDB lors de la création du schéma prédéfini. Cependant, nous n'aborderons pas cette option dans cette section. Vous pouvez en voir un exemple dans la section Lancement d'un schéma.

Nous examinerons plutôt toutes les sources de données prises AWS AppSync en charge. De nombreux facteurs entrent en ligne de compte pour choisir la bonne solution pour votre application. Les sections ci-dessous fournissent un contexte supplémentaire pour chaque source de données. Pour des informations générales sur les sources de données, consultez la section Sources de données.

Amazon DynamoDB

Amazon DynamoDB est l'une des principales solutions AWS de stockage pour les applications évolutives. Le composant principal de DynamoDB est la table, qui est simplement un ensemble de données. Vous créerez généralement des tables basées sur des entités telles que Book ouAuthor. Les informations d'entrée de table sont stockées sous forme d'éléments, qui sont des groupes de champs uniques à chaque entrée. Un élément complet représente une ligne/un enregistrement dans la base de données. Par exemple, un élément d'une Book entrée peut inclure title et author avec leurs valeurs. Les champs individuels tels que title et author sont appelés attributs, qui sont similaires aux valeurs de colonne dans les bases de données relationnelles.

Comme vous pouvez le deviner, les tables seront utilisées pour stocker les données de votre application. AWS AppSync vous permet de connecter vos tables DynamoDB à votre GraphQL API pour manipuler des données. Prenez ce cas d'utilisation tiré du blog Web et mobile de Frontend. Cette application permet aux utilisateurs de s'inscrire à une application de réseau social. Les utilisateurs peuvent rejoindre des groupes et télécharger des publications qui sont diffusées aux autres utilisateurs abonnés au groupe. Leur application stocke les informations relatives aux utilisateurs, aux publications et aux groupes d'utilisateurs dans DynamoDB. Le GraphQL API (géré par AWS AppSync) s'interface avec la table DynamoDB. Lorsqu'un utilisateur apporte une modification au système qui sera répercutée sur le front-end, API GraphQL récupère ces modifications et les diffuse aux autres utilisateurs en temps réel.

AWS Lambda

Lambda est un service piloté par les événements qui crée automatiquement les ressources nécessaires pour exécuter le code en réponse à un événement. Lambda utilise des fonctions, qui sont des instructions de groupe contenant le code, les dépendances et les configurations pour exécuter une ressource. Les fonctions s'exécutent automatiquement lorsqu'elles détectent un déclencheur, un groupe d'activités qui invoque votre fonction. Un déclencheur peut être quelque chose comme une application qui passe un API appel, un AWS service de votre compte qui lance une ressource, etc. Lorsqu'elles sont déclenchées, les fonctions traitent les événements, qui sont des JSON documents contenant les données à modifier.

Lambda est idéal pour exécuter du code sans avoir à fournir les ressources nécessaires à son exécution. Prenez ce cas d'utilisation tiré du blog Web et mobile de Frontend. Ce cas d'utilisation est un peu similaire à celui présenté dans la section DynamoDB. Dans cette application, GraphQL API est chargé de définir les opérations pour des choses telles que l'ajout de publications (mutations) et la récupération de ces données (requêtes). Pour implémenter les fonctionnalités de leurs opérations (par exemple,,getPostsByAuthor ( author: String ! ) : [ Post ])getPost ( id: String ! ) : Post, ils utilisent les fonctions Lambda pour traiter les demandes entrantes. Dans le cadre de l'option 2 : AWS AppSync avec le résolveur Lambda, ils utilisent le AWS AppSync service pour gérer leur schéma et lier une source de données Lambda à l'une des opérations. Lorsque l'opération est appelée, Lambda s'interface avec le RDS proxy Amazon pour exécuter la logique métier sur la base de données.

Amazon RDS

Amazon vous RDS permet de créer et de configurer rapidement des bases de données relationnelles. Dans AmazonRDS, vous allez créer une instance de base de données générique qui servira d'environnement de base de données isolé dans le cloud. Dans ce cas, vous utiliserez un moteur de base de données, qui est le RDBMS logiciel lui-même (PostgreSQL, MySQL, etc.). Le service décharge une grande partie du travail de backend en fournissant une évolutivité grâce à l'infrastructure, aux services AWS de sécurité tels que les correctifs et le chiffrement, et en réduisant les coûts administratifs liés aux déploiements.

Prenez le même cas d'utilisation que celui de la section Lambda. Dans le cadre de l'option 3 : AWS AppSync avec Amazon RDS Resolver, une autre option présentée consiste à lier directement le API GraphQL AWS AppSync à AmazonRDS. À l'aide d'une donnée API, ils associent la base de données au GraphQLAPI. Un résolveur est attaché à un champ (généralement une requête, une mutation ou un abonnement) et implémente les SQL instructions nécessaires pour accéder à la base de données. Lorsqu'une demande appelant le champ est faite par le client, le résolveur exécute les instructions et renvoie la réponse.

Amazon EventBridge

Dans EventBridge, vous allez créer des bus d'événements, qui sont des pipelines qui reçoivent des événements provenant de services ou d'applications que vous associez (la source des événements) et qui les traitent selon un ensemble de règles. Un événement est un changement d'état dans un environnement d'exécution, tandis qu'une règle est un ensemble de filtres pour les événements. Une règle suit un modèle d'événement ou les métadonnées du changement d'état d'un événement (identifiant, région, numéro de compte, ARN (s), etc.). Lorsqu'un événement correspond au modèle d'événement, EventBridge il est envoyé à travers le pipeline vers le service de destination (cible) et déclenche l'action spécifiée dans la règle.

EventBridge est utile pour acheminer les opérations de changement d'état vers un autre service. Prenez ce cas d'utilisation tiré du blog Web et mobile de Frontend. L'exemple illustre une solution de commerce électronique dans laquelle plusieurs équipes gèrent différents services. L'un de ces services fournit des mises à jour des commandes au client à chaque étape de la livraison (commande passée, en cours, expédiée, livrée, etc.) sur le front-end. Cependant, l'équipe frontale qui gère ce service n'a pas un accès direct aux données du système de commande, car celles-ci sont gérées par une équipe principale distincte. Le système de commande de l'équipe principale est également décrit comme une boîte noire. Il est donc difficile de glaner des informations sur la manière dont l'équipe structure ses données. Cependant, l'équipe principale a mis en place un système qui publiait les données des commandes via un bus d'événements géré par EventBridge. Pour accéder aux données provenant du bus d'événements et les acheminer vers le front-end, l'équipe du front-end a créé une nouvelle cible pointant vers son API GraphQL installé. AWS AppSync Ils ont également créé une règle pour envoyer uniquement les données relatives à la mise à jour de la commande. Lorsqu'une mise à jour est effectuée, les données du bus d'événements sont envoyées au GraphQLAPI. Le schéma du API traite les données, puis les transmet au front-end.

Aucune source de données

Si vous n'avez pas l'intention d'utiliser une source de données, vous pouvez la définir surnone. Une source de none données, bien qu'elle soit toujours explicitement classée comme source de données, n'est pas un support de stockage. Généralement, un résolveur invoque une ou plusieurs sources de données à un moment donné pour traiter la demande. Il existe toutefois des situations dans lesquelles il n'est pas nécessaire de manipuler une source de données. La définition de la source de données sur none exécutera la demande, ignorera l'étape d'appel des données, puis exécutera la réponse.

Prenez le même cas d'utilisation que celui de la EventBridge section. Dans le schéma, la mutation traite la mise à jour du statut, puis l'envoie aux abonnés. Pour rappeler le fonctionnement des résolveurs, il y a généralement au moins un appel de source de données. Cependant, les données de ce scénario ont déjà été envoyées automatiquement par le bus d'événements. Cela signifie que la mutation n'est pas nécessaire pour effectuer un appel de source de données ; le statut de la commande peut simplement être géré localement. La mutation est définie surnone, qui agit comme une valeur directe sans appel de source de données. Le schéma est ensuite renseigné avec les données, qui sont envoyées aux abonnés.

OpenSearch

Amazon OpenSearch Service est une suite d'outils permettant de mettre en œuvre la recherche en texte intégral, la visualisation des données et la journalisation. Vous pouvez utiliser ce service pour interroger les données structurées que vous avez téléchargées.

Dans ce service, vous allez créer des instances de OpenSearch. C'est ce qu'on appelle des nœuds. Dans un nœud, vous allez ajouter au moins un index. D'un point de vue conceptuel, les indices sont un peu comme des tables dans des bases de données relationnelles. (Cependant, il OpenSearch n'est pas ACID conforme, il ne doit donc pas être utilisé de cette façon). Vous allez remplir votre index avec les données que vous téléchargez sur le OpenSearch service. Lorsque vos données sont téléchargées, elles sont indexées dans une ou plusieurs partitions présentes dans l'index. Une partition est similaire à une partition de votre index qui contient certaines de vos données et peut être interrogée séparément des autres partitions. Une fois téléchargées, vos données seront structurées sous forme de JSON fichiers appelés documents. Vous pouvez ensuite interroger le nœud pour obtenir des données dans le document.

HTTPpoints de terminaison

Vous pouvez utiliser les HTTP points de terminaison comme sources de données. AWS AppSync peut envoyer des demandes aux points de terminaison avec les informations pertinentes telles que les paramètres et la charge utile. La HTTP réponse sera exposée au résolveur, qui renverra la réponse finale une fois ses opérations terminées.

Ajouter une source de données

Si vous avez créé une source de données, vous pouvez la lier au AWS AppSync service et, plus précisément, auAPI.

Console

  1. Connectez-vous à la AppSyncconsole AWS Management Console et ouvrez-la.

    1. Choisissez votre API dans le tableau de bord.

    2. Dans la barre latérale, sélectionnez Sources de données.

  2. Choisissez Create data source.

    1. Donnez un nom à votre source de données. Vous pouvez également lui donner une description, mais c'est facultatif.

    2. Choisissez votre type de source de données.

    3. Pour DynamoDB, vous devez choisir votre région, puis le tableau dans la région. Vous pouvez dicter des règles d'interaction avec votre table en choisissant de créer un nouveau rôle de table générique ou en important un rôle existant pour la table. Vous pouvez activer le versionnement, qui permet de créer automatiquement des versions des données pour chaque demande lorsque plusieurs clients tentent de mettre à jour les données en même temps. Le versionnement est utilisé pour conserver et gérer plusieurs variantes de données à des fins de détection et de résolution de conflits. Vous pouvez également activer la génération automatique de schéma, qui prend votre source de données et génère certaines Query des opérations nécessaires pour y accéder dans votre schéma. CRUD List

      En OpenSearch effet, vous devrez choisir votre région, puis le domaine (cluster) de la région. Vous pouvez dicter des règles d'interaction avec votre domaine en choisissant de créer un nouveau rôle de table générique ou en important un rôle existant pour la table.

      Pour Lambda, vous devrez choisir votre région, puis celle ARN de la fonction Lambda dans la région. Vous pouvez dicter des règles d'interaction avec votre fonction Lambda en choisissant de créer un nouveau rôle de table générique ou en important un rôle existant pour la table.

      CarHTTP, vous devrez saisir votre HTTP point de terminaison.

      En EventBridge effet, vous devrez choisir votre région, puis le bus événementiel de la région. Vous pouvez dicter des règles d'interaction avec votre bus d'événements en choisissant de créer un nouveau rôle de table générique ou en important un rôle existant pour la table.

      En RDS effet, vous devrez choisir votre région, puis le magasin secret (nom d'utilisateur et mot de passe), le nom de la base de données et le schéma.

      Dans aucun cas, vous ajouterez une source de données sans source de données réelle. Cela permet de gérer les résolveurs localement plutôt que par le biais d'une source de données réelle.

      Note

      Si vous importez des rôles existants, ils ont besoin d'une politique de confiance. Pour plus d'informations, consultez la politique de IAM confiance.

  3. Choisissez Créer.

    Note

    Si vous créez une source de données DynamoDB, vous pouvez également accéder à la page Schéma de la console, choisir Créer des ressources en haut de la page, puis remplir un modèle prédéfini à convertir en table. Dans cette option, vous allez remplir ou importer le type de base, configurer les données de base de la table, y compris la clé de partition, et passer en revue les modifications du schéma.

CLI

  • Créez votre source de données en exécutant la create-data-sourcecommande.

    Vous devez entrer quelques paramètres pour cette commande particulière :

    1. Le api-id de votreAPI.

    2. Celui name de ta table.

    3. La source type de données. Selon le type de source de données que vous choisissez, vous devrez peut-être saisir une balise service-role-arn et une -config balise.

    Voici un exemple de commande :

     aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name data_source_name --type data_source_type --service-role-arn arn:aws:iam::107289374856:role/role_name --[data_source_type]-config {params}
CDK
Astuce

Avant de l'utiliserCDK, nous vous recommandons CDK de consulter la documentation officielle ainsi que AWS AppSync les CDKréférences.

Les étapes répertoriées ci-dessous ne montreront qu'un exemple général de l'extrait 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 ajouter votre source de données spécifique, vous devez ajouter la construction à votre fichier de pile. Vous trouverez une liste des types de sources de données ici :

  1. En général, vous devrez peut-être ajouter la directive d'importation au service que vous utilisez. Par exemple, il peut suivre les formes suivantes :

    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'

    Par exemple, voici comment vous pouvez importer les services AWS AppSync et DynamoDB :

    import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';

  2. Certains services RDS nécessitent une configuration supplémentaire dans le fichier de pile avant de créer la source de données (par exemple, VPC création, rôles et informations d'accès). Consultez les exemples dans les CDK pages correspondantes pour plus d'informations.

  3. Pour la plupart des sources de données, en particulier les AWS services, vous allez créer une nouvelle instance de la source de données dans votre fichier de pile. En général, cela ressemblera à ce qui suit :

    const add_data_source_func = new service_scope.resource_name(scope: Construct, id: string, props: data_source_props);

    Par exemple, voici un exemple de table Amazon DynamoDB :

    const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  partitionKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  sortKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
  tableClass: dynamodb.TableClass.STANDARD,
});
    Note

    La plupart des sources de données auront au moins un accessoire obligatoire (indiqué sans ? symbole). Consultez la CDK documentation pour savoir quels accessoires sont nécessaires.

  4. Ensuite, vous devez lier la source de données au GraphQLAPI. La méthode recommandée consiste à l'ajouter lorsque vous créez une fonction pour votre résolveur de pipeline. Par exemple, l'extrait ci-dessous est une fonction qui analyse tous les éléments d'une table DynamoDB :

    const add_func = new appsync.AppsyncFunction(this, 'func_ID', {
  name: 'func_name_in_console',
  add_api,
  dataSource: add_api.addDynamoDbDataSource('data_source_name_in_console', 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,
});

    Dans les dataSource accessoires, vous pouvez appeler le API GraphQL add_api () et utiliser l'une de ses méthodes intégrées addDynamoDbDataSource () pour établir l'association entre la table et le GraphQL. API Les arguments sont le nom de ce lien qui existera dans la AWS AppSync console (data_source_name_in_consoledans cet exemple) et la méthode de table (add_ddb_table). Plus d'informations sur ce sujet seront révélées dans la section suivante lorsque vous commencerez à créer des résolveurs.

    Il existe d'autres méthodes pour lier une source de données. Techniquement, vous pouvez les ajouter api à la liste des accessoires dans la fonction de table. Par exemple, voici l'extrait de l'étape 3 mais avec un api accessoire contenant un GraphQL : API

    const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {

 ...

  api: add_api
});

    Vous pouvez également appeler la GraphqlApi construction séparément :

    const add_api = new appsync.GraphqlApi(this, 'API_ID', {
  ...
});

const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
  ...
});

const link_data_source = add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table);

    Nous recommandons de créer l'association uniquement dans les accessoires de la fonction. Sinon, vous devrez soit lier votre fonction de résolution à la source de données manuellement dans la AWS AppSync console (si vous souhaitez continuer à utiliser la valeur de la consoledata_source_name_in_console), soit créer une association distincte dans la fonction sous un autre nom, par exempledata_source_name_in_console_2. Cela est dû aux limites de la manière dont les accessoires traitent les informations.

    Note

    Vous devrez redéployer l'application pour voir vos modifications.

IAMpolitique de confiance

Si vous utilisez un IAM rôle existant pour votre source de données, vous devez accorder à ce rôle les autorisations appropriées pour effectuer des opérations sur votre AWS ressource, par exemple PutItem sur une table Amazon DynamoDB. Vous devez également modifier la politique de confiance associée à ce rôle afin de permettre son utilisation AWS AppSync pour l'accès aux ressources, comme indiqué dans l'exemple de politique suivant :

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

Vous pouvez également ajouter des conditions à votre politique de confiance afin de limiter l'accès à la source de données comme vous le souhaitez. Actuellement, SourceArn et SourceAccount les clés peuvent être utilisées dans ces conditions. Par exemple, la politique suivante limite l'accès à votre source de données au compte 123456789012 :

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

Vous pouvez également limiter l'accès à une source de données à une source de données spécifiqueAPI, par exemple en abcdefghijklmnopq appliquant la politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-west-2:123456789012:apis/abcdefghijklmnopq"
        }
      }
    }
  ]
}

Vous pouvez limiter l'accès à tous AWS AppSync APIs ceux d'une région spécifique, par exemple en us-east-1 appliquant la politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "appsync.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:appsync:us-east-1:123456789012:apis/*"
        }
      }
    }
  ]
}

Dans la section suivante (Configuration des résolveurs), nous allons ajouter notre logique métier de résolveur et l'associer aux champs de notre schéma pour traiter les données de notre source de données.

Pour plus d'informations sur la configuration de la politique de rôle, consultez la section Modification d'un rôle dans le Guide de IAM l'utilisateur.

Pour plus d'informations sur l'accès multicompte aux AWS Lambda résolveurs pour AWS AppSync, voir Création de résolveurs multicomptes AWS Lambda pour. AWS AppSync