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.

Fusionner des API dans AWS AppSync

À mesure que l'utilisation de GraphQL se développe au sein d'une organisation, des compromis entre la facilité d'utilisation des API et la rapidité de développement des API peuvent survenir. D'une part, les organisations adoptent AWS AppSync GraphQL pour simplifier le développement d'applications. Les développeurs disposent ainsi d'une API flexible qu'ils peuvent utiliser pour accéder, manipuler et combiner en toute sécurité les données d'un ou de plusieurs domaines de données en un seul appel réseau. D'autre part, les équipes d'une organisation responsables des différents domaines de données combinés dans un seul point de terminaison d'API GraphQL peuvent souhaiter pouvoir créer, gérer et déployer des mises à jour d'API indépendamment les unes des autres. Cela augmente leur vitesse de développement.

Pour résoudre cette tension, la fonctionnalité API AWS AppSync fusionnée permet aux équipes de différents domaines de données de créer et de déployer indépendamment des AWS AppSync API (par exemple, des schémas GraphQL, des résolveurs, des sources de données et des fonctions), qui peuvent ensuite être combinées en une seule API fusionnée. Cela donne aux entreprises la possibilité de gérer une API multidomaine simple à utiliser et permet aux différentes équipes qui contribuent à cette API d'effectuer des mises à jour d'API rapidement et indépendamment.

Le schéma suivant montre le flux de travail d'API fusionné :

À l'aide des API fusionnées, les organisations peuvent importer les ressources de plusieurs AWS AppSync API sources indépendantes dans un seul point de terminaison d'API AWS AppSync fusionnée. Pour ce faire, vous AWS AppSync permet de créer une liste d' AWS AppSync API sources, puis de fusionner toutes les métadonnées associées aux API sources, notamment le schéma, les types, les sources de données, les résolveurs et les fonctions, dans une nouvelle API AWS AppSync fusionnée.

Lors des fusions, il est possible qu'un conflit de fusion se produise en raison d'incohérences dans le contenu des données de l'API source, telles que des conflits de dénomination de type lors de la combinaison de plusieurs schémas. Pour les cas d'utilisation simples où aucune définition dans les API source n'entre en conflit, il n'est pas nécessaire de modifier les schémas d'API source. L'API fusionnée qui en résulte importe simplement tous les types, résolveurs, sources de données et fonctions à partir des AWS AppSync API sources d'origine. Pour les cas d'utilisation complexes où des conflits surviennent, ils users/teams devront résoudre les conflits par différents moyens. AWS AppSync fournit aux utilisateurs plusieurs outils et exemples permettant de réduire les conflits de fusion.

Les fusions suivantes configurées dans AWS AppSync propageront les modifications apportées aux API sources à l'API fusionnée associée.

API et fédération fusionnées

Il existe de nombreuses solutions et modèles dans la communauté GraphQL pour combiner des schémas GraphQL et permettre la collaboration en équipe via un graphe partagé. AWS AppSync Les API fusionnées adoptent une approche basée sur le temps de construction pour la composition des schémas, dans laquelle les API sources sont combinées dans une API fusionnée distincte. Une autre approche consiste à superposer un routeur d'exécution sur plusieurs API ou sous-graphes sources. Dans cette approche, le routeur reçoit une demande, fait référence à un schéma combiné qu'il gère sous forme de métadonnées, construit un plan de demande, puis distribue les éléments de la demande dans son sous-ensemble sous-jacent. graphs/servers Le tableau suivant compare l'approche de création de l'API AWS AppSync fusionnée aux approches d'exécution basées sur un routeur pour la composition des schémas GraphQL :

* Les API AWS AppSync fusionnées ne peuvent être associées qu'aux API AWS AppSync sources. Si vous avez besoin d'assistance pour la composition de schémas entre AWS AppSync et sans AWS AppSync sous-graphes, vous pouvez connecter une ou plusieurs API AWS AppSync GraphQL Merged à une and/or solution basée sur un routeur. Par exemple, consultez le blog de référence pour ajouter des AWS AppSync API en tant que sous-graphe à l'aide d'une architecture basée sur un routeur avec Apollo Federation v2 : Apollo GraphQL Federation avec. AWS AppSync

Résolution des conflits d'API fusionnées

En cas de conflit de fusion, AWS AppSync fournit aux utilisateurs plusieurs outils et exemples pour les aider à résoudre le ou les problèmes.

Directives de schéma d'API fusionnées

AWS AppSync a introduit plusieurs directives GraphQL qui peuvent être utilisées pour réduire ou résoudre les conflits entre les API sources :

Pour afficher les directives du schéma d'utilité fournies par les directives, considérez l'exemple suivant :

Dans cet exemple, supposons que nous voulons fusionner deux API sources. On nous donne deux schémas qui créent et récupèrent des publications (par exemple, une section de commentaires ou des publications sur les réseaux sociaux). En supposant que les types et les champs soient très similaires, le risque de conflit est élevé lors d'une opération de fusion. Les extraits ci-dessous présentent les types et les champs de chaque schéma.

Le premier fichier, appelé Source1.graphql, est un schéma GraphQL qui permet à un utilisateur de créer à l'Postsaide de la putPost mutation. Chacune Post contient un titre et un identifiant. L'identifiant est utilisé pour faire référence aux User informations de l'annonceur (e-mail et adresse) et à la Message ou à la charge utile (contenu). Le User type est annoté à l'aide de la balise @canonical.

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post {
    id: ID!
    title: String!
}

type Message {
   id: ID!
   content: String
}

type User @canonical {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
}

Le second fichier, appelé Source2.graphql, est un schéma GraphQL qui fait des choses très similaires à. Source1.graphql Notez toutefois que les champs de chaque type sont différents. Lors de la fusion de ces deux schémas, il peut y avoir des conflits de fusion en raison de ces différences.

Notez également comment contient Source2.graphql également plusieurs directives pour réduire ces conflits. Le Post type est annoté à l'aide d'une balise @hidden pour se masquer lors de l'opération de fusion. Le Message type est annoté avec la balise @renamed pour modifier le nom du type ChatMessage en cas de conflit de dénomination avec un autre Message type.

# This snippet represents a file called Source2.graphql

type Post @hidden  {
    id: ID!
    title: String!
    internalSecret: String!
}

type Message @renamed(to: "ChatMessage") {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

# Stub user so that we can link the canonical definition from Source1
type User {
   id: ID!
}

type Query {
    getPost(id: ID!): Post
    getMessage(id: ID!): Message @renamed(to: "getChatMessage")
}

Lorsque la fusion se produit, le résultat produira le MergedSchema.graphql fichier :

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

# Post from Source2 was hidden so only uses the Source1 definition. 
type Post {
    id: ID!
    title: String!
}

# Renamed from Message to resolve the conflict
type ChatMessage {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

type Message {
   id: ID!
   content: String
}

# Canonical definition from Source1
type User {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
    
    # Renamed from getMessage
    getChatMessage(id: ID!): ChatMessage
}

Plusieurs choses se sont produites lors de la fusion :

Il existe également le cas où aucune directive n'est ajoutée à un type en conflit. Ici, le type fusionné inclura l'union de tous les champs de toutes les définitions de source de ce type. Par exemple, considérez l'exemple suivant :

Ce schéma, appelé Source1.graphql, permet de créer et de récupérerPosts. La configuration est similaire à l'exemple précédent, mais avec moins d'informations.

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
}

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

Ce schéma, appelé Source2.graphql, permet de créer et de récupérer Reviews (par exemple, des évaluations de films ou des critiques de restaurants). Reviewssont associés à Post la même valeur d'identification. Ensemble, ils contiennent le titre, l'identifiant de la publication et le message de charge utile de la publication de critique complète.

Lors de la fusion, il y aura un conflit entre les deux Post types. Comme aucune annotation ne permet de résoudre ce problème, le comportement par défaut consiste à effectuer une opération d'union sur les types en conflit.

# This snippet represents a file called Source2.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
}

type Post  {
    id: ID!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getReview(id: ID!): Review
}

Lorsque la fusion se produit, le résultat produira le MergedSchema.graphql fichier :

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getPost(id: ID!): Post
    getReview(id: ID!): Review
}

Plusieurs choses se sont produites lors de la fusion :

Gestion des résolveurs sur les types partagés

Dans l'exemple ci-dessus, considérez le cas où Source1.graphql a configuré un résolveur d'unités activéQuery.getPost, qui utilise une source de données DynamoDB nommée. PostDatasource Ce résolveur renverra le id et title d'un Post type. Maintenant, considérez Source2.graphql que vous avez configuré un résolveur de pipeline surPost.reviews, qui exécute deux fonctions. Function1dispose d'une source de None données associée pour effectuer des contrôles d'autorisation personnalisés. Function2possède une source de données DynamoDB associée pour interroger la reviews table.

query GetPostQuery {
    getPost(id: "1") {
        id,
        title,
        reviews
    }
}

Lorsque la requête ci-dessus est exécutée par un client vers le point de terminaison de l'API fusionnée, le AWS AppSync service exécute d'abord le résolveur d'unités pour Query.getPost fromSource1, qui appelle PostDatasource et renvoie les données depuis DynamoDB. Ensuite, il exécute le résolveur de Post.reviews pipeline dans lequel Function1 exécute une logique d'autorisation personnalisée et Function2 renvoie les avis en $context.source fonction de la valeur id trouvée. Le service traite la demande comme une seule exécution GraphQL, et cette simple demande ne nécessitera qu'un seul jeton de demande.

Gestion des conflits entre résolveurs sur les types partagés

Prenons le cas suivant où nous implémentons également un résolveur Query.getPost afin de fournir plusieurs champs à la fois au-delà du résolveur de champs dans. Source2 Source1.graphqlpeut ressembler à ceci :

# This snippet represents a file called Source1.graphql

type Post  {
    id: ID!
    title: String!
    date: AWSDateTime!
}

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

Source2.graphqlpeut ressembler à ceci :

# This snippet represents a file called Source2.graphql

type Post  {
  id: ID!
  content: String!
  contentHash: String! 
  author: String! 
}

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

Toute tentative de fusion de ces deux schémas générera une erreur de fusion car les API AWS AppSync fusionnées ne permettent pas d'associer plusieurs résolveurs de source au même champ. Afin de résoudre ce conflit, vous pouvez implémenter un modèle de résolution de champs qui nécessiterait l'ajout Source2.graphql d'un type distinct qui définira les champs qui lui appartiennent à partir du Post type. Dans l'exemple suivant, nous ajoutons un type appeléPostInfo, qui contient les champs de contenu et d'auteur qui seront résolus par Source2.graphql. Source1.graphqlimplémentera le résolveur attaché àQuery.getPost, alors qu'Source2.graphqlil associera désormais un résolveur pour s'Post.postInfoassurer que toutes les données peuvent être récupérées avec succès :

type Post  {
  id: ID!
  postInfo: PostInfo
}

type PostInfo {
   content: String!
   contentHash: String!
   author: String!
}

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

Bien que la résolution d'un tel conflit nécessite la réécriture des schémas d'API source et, éventuellement, la modification des requêtes des clients, l'avantage de cette approche est que la propriété des résolveurs fusionnés reste claire pour toutes les équipes responsables des sources.

Gestion des autorisations sur les champs partagés

Lorsque deux API sources ou plus déclarent le même champ, la fusion combine les directives d'autorisation de chaque déclaration. Les clients peuvent ensuite accéder au champ fusionné via l'un de ces modes d'autorisation. Si une API source déclare un champ avec @aws_iam et qu'une autre API source déclare le même champ avec@aws_api_key, le champ fusionné accepte l'un ou l'autre, et un client qui ne détient qu'une clé d'API peut l'invoquer.

Pour conserver l'autorisation d'un champ telle que définie par votre API source, annotez le champ @canonical et déclarez la directive d'autorisation dont vous avez besoin sur le champ lui-même. Dans l'exemple suivant, Source1.graphql possède le résolveur pour protectedRead et requiert l'autorisation IAM :

# This snippet represents a file called Source1.graphql

type Query {
    protectedRead: String @aws_iam @canonical
}

# This snippet represents a file called Source2.graphql

type Query {
    protectedRead: String @aws_api_key
}

Lorsque la fusion a lieu, la définition de Source1.graphql est prioritaire :

# This snippet represents a file called MergedSchema.graphql

type Query {
    protectedRead: String @aws_iam
}

Sans l'annotation @canonical, le champ fusionné seraitprotectedRead: String @aws_api_key @aws_iam. Un client détenant uniquement la clé d'API de l'API fusionnée peut alors l'invoquer.

Si votre API source possède le résolveur du champ, annotez le champ dans cette API source, car son résolveur renvoie les données.

Deux conditions s'appliquent :

Déclarer la directive d'autorisation sur le terrain

@canonical préserve le champ tel qu'il a été déclaré. Un champ annoté @canonical sans directive d'autorisation propre utilise le mode d'autorisation principal de votre API source, qui peut être plus permissif que vous ne le souhaitez.

Annoter un champ dans une seule API source

Si deux API sources annotent le même champ comme étant canonique, la fusion échoue avec le message d'erreur. Multiple subschemas cannot declare the same field as canonical

Appliquez @canonical au niveau du champ plutôt qu'au niveau du type pour limiter l'autorisation sur des champs spécifiques. Cela permet toujours à d'autres API sources d'ajouter des champs supplémentaires au même type. Ce guide s'applique aux champs sur QueryMutation, et Subscription ainsi qu'aux champs sur les types d'objets.

Si vous ne souhaitez pas qu'un champ apparaisse dans l'API fusionnée, utilisez plutôt @hidden. Pour de plus amples informations, veuillez consulter Directives de schéma d'API fusionnées.

Configuration des schémas

Deux parties sont chargées de configurer les schémas pour créer une API fusionnée :

Comme le schéma de votre API fusionnée est créé à partir des schémas de vos API sources associées, il est en lecture seule. Cela signifie que les modifications du schéma doivent être initiées dans vos API sources. Dans la AWS AppSync console, vous pouvez basculer entre votre schéma fusionné et les schémas individuels des API sources incluses dans votre API fusionnée à l'aide de la liste déroulante située au-dessus de la fenêtre Schéma.

Configuration des modes d'autorisation

Plusieurs modes d'autorisation sont disponibles pour protéger votre API fusionnée. Pour en savoir plus sur les modes d'autorisation dans AWS AppSync, consultez la section Autorisation et authentification.

Les modes d'autorisation suivants peuvent être utilisés avec les API fusionnées :

Les modes d'autorisation d'une API fusionnée sont configurés par le propriétaire de l'API fusionnée. Au moment d'une opération de fusion, l'API fusionnée doit inclure le mode d'autorisation principal configuré sur une API source, soit en tant que mode d'autorisation principal, soit en tant que mode d'autorisation secondaire. Sinon, il sera incompatible et l'opération de fusion échouera en cas de conflit. Lorsque vous utilisez des directives d'authentification multiples dans les API sources, le processus de fusion est capable de fusionner automatiquement ces directives dans le point de terminaison unifié. Si le mode d'autorisation principal de l'API source ne correspond pas au mode d'autorisation principal de l'API fusionnée, ces directives d'authentification seront automatiquement ajoutées pour garantir la cohérence du mode d'autorisation pour les types de l'API source.

Configuration des rôles d'exécution

Lorsque vous créez une API fusionnée, vous devez définir un rôle de service. Un rôle AWS de service est un rôle de gestion des AWS identités et des accès (IAM) utilisé par les AWS services pour effectuer des tâches en votre nom.

Dans ce contexte, il est nécessaire que votre API fusionnée exécute des résolveurs qui accèdent aux données provenant des sources de données configurées dans vos API sources. Le rôle de service requis pour cela est lemergedApiExecutionRole, et il doit disposer d'un accès explicite pour exécuter des requêtes sur les API sources incluses dans votre API fusionnée via l'autorisation appsync:SourceGraphQL IAM. Lors de l'exécution d'une requête GraphQL, le AWS AppSync service assume ce rôle de service et autorise le rôle à effectuer l'appsync:SourceGraphQLaction.

AWS AppSync prend en charge l'autorisation ou le refus de cette autorisation sur des champs de niveau supérieur spécifiques de la demande, comme le fonctionnement du mode d'autorisation IAM pour les API IAM. Pour les champs qui ne sont pas de niveau AWS AppSync supérieur, vous devez définir l'autorisation sur l'ARN de l'API source lui-même. Afin de restreindre l'accès à des champs spécifiques qui ne sont pas de niveau supérieur dans l'API fusionnée, nous vous recommandons d'implémenter une logique personnalisée dans votre Lambda ou de masquer les champs de l'API source dans l'API fusionnée à l'aide de la directive @hidden. Si vous souhaitez autoriser le rôle à effectuer toutes les opérations de données au sein d'une API source, vous pouvez ajouter la politique ci-dessous. Notez que la première entrée de ressource permet d'accéder à tous les champs de niveau supérieur et que la deuxième entrée couvre les résolveurs enfants qui autorisent sur la ressource d'API source elle-même :

JSON

{
    "Version":"2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/*", 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

Si vous souhaitez limiter l'accès à un champ de niveau supérieur spécifique, vous pouvez utiliser une politique comme celle-ci :

JSON

{
    "Version":"2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

Vous pouvez également utiliser l'assistant de création d'API de AWS AppSync console pour générer un rôle de service afin de permettre à votre API fusionnée d'accéder aux ressources configurées dans les API sources qui se trouvent dans le même compte que votre API fusionnée. Si vos API sources ne se trouvent pas dans le même compte que votre API fusionnée, vous devez d'abord partager vos ressources à l'aide de AWS Resource Access Manager (AWS RAM).

Configuration d'API fusionnées entre comptes à l'aide de AWS RAM

Lorsque vous créez une API fusionnée, vous pouvez éventuellement associer des API sources provenant d'autres comptes qui ont été partagés via AWS Resource Access Manager (AWS RAM). AWS RAM vous permet de partager vos ressources en toute sécurité entre les AWS comptes, au sein de votre organisation ou de vos unités organisationnelles (UO), ainsi qu'avec les rôles et les utilisateurs IAM.

AWS AppSync s'intègre afin de prendre AWS RAM en charge la configuration et l'accès aux API sources sur plusieurs comptes à partir d'une seule API fusionnée. AWS RAM vous permet de créer un partage de ressources ou un conteneur de ressources et les ensembles d'autorisations qui seront partagés pour chacune d'entre elles. Vous pouvez ajouter AWS AppSync des API à un partage de ressources dans AWS RAM. Dans un partage de ressources, AWS AppSync fournit trois ensembles d'autorisations différents qui peuvent être associés à une AWS AppSync API dans la RAM :

AWS AppSync prend également en charge les autorisations gérées par le client. Lorsque l'une des autorisations AWS gérées fournies ne fonctionne pas, vous pouvez créer votre propre autorisation gérée par le client. Customer-managed les autorisations sont des autorisations gérées que vous créez et gérez en spécifiant avec précision quelles actions peuvent être effectuées dans quelles conditions avec les ressources partagées AWS RAM. AWS AppSync vous permet de choisir parmi les actions suivantes lors de la création de votre propre autorisation :

Une fois que vous avez correctement partagé une API source ou une API fusionnée AWS RAM et que, si nécessaire, l'invitation à partager des ressources a été acceptée, elle sera visible dans la AWS AppSync console lorsque vous créez ou mettez à jour les associations d'API source sur votre API fusionnée. Vous pouvez également répertorier toutes les AWS AppSync API qui ont été partagées AWS RAM avec votre compte, quelle que soit l'autorisation définie, en appelant l'ListGraphqlApisopération fournie par AWS AppSync et en utilisant le filtre OTHER_ACCOUNTS propriétaire.

Fusionner

Gestion des fusions

Les API fusionnées sont destinées à faciliter la collaboration en équipe sur un point de AWS AppSync terminaison unifié. Les équipes peuvent faire évoluer indépendamment leurs propres API GraphQL sources isolées dans le backend, tandis que le AWS AppSync service gère l'intégration des ressources dans le point de terminaison unique de l'API fusionnée afin de réduire les frictions liées à la collaboration et de réduire les délais de développement.

Auto-merges

Les API sources associées à votre API AWS AppSync fusionnée peuvent être configurées pour fusionner automatiquement (fusion automatique) dans l'API fusionnée après toute modification apportée à l'API source. Cela garantit que les modifications apportées par l'API source sont toujours propagées au point de terminaison de l'API fusionnée en arrière-plan. Toute modification apportée au schéma de l'API source sera mise à jour dans l'API fusionnée tant qu'elle n'introduit pas de conflit de fusion avec une définition existante dans l'API fusionnée. Si la mise à jour de l'API source met à jour un résolveur, une source de données ou une fonction, la ressource importée sera également mise à jour. Lorsqu'un nouveau conflit ne peut pas être résolu automatiquement (résolution automatique), la mise à jour du schéma de l'API fusionnée est rejetée en raison d'un conflit non pris en charge lors de l'opération de fusion. Le message d'erreur est disponible dans la console pour chaque association d'API source dont le statut estMERGE_FAILED. Vous pouvez également consulter le message d'erreur en appelant l'GetSourceApiAssociationopération pour une association d'API source donnée à l'aide du AWS SDK ou de l' AWS interface de ligne de commande comme suit :

aws appsync get-source-api-association --merged-api-identifier <Merged API ARN> --association-id <SourceApiAssociation id>

Cela produira un résultat au format suivant :

{
    "sourceApiAssociation": {
        "associationId": "<association id>",
        "associationArn": "<association arn>",
        "sourceApiId": "<source api id>",
        "sourceApiArn": "<source api arn>",
        "mergedApiArn": "<merged api arn>",
        "mergedApiId": "<merged api id>",
        "sourceApiAssociationConfig": {
            "mergeType": "MANUAL_MERGE"
        },
        "sourceApiAssociationStatus": "MERGE_FAILED",
        "sourceApiAssociationStatusDetail": "Unable to resolve conflict on object with name title: Merging is not supported for fields with different types."
    }
}

Fusions manuelles

Le paramètre par défaut d'une API source est une fusion manuelle. Pour fusionner les modifications apportées aux API sources depuis la dernière mise à jour de l'API fusionnée, le propriétaire de l'API source peut invoquer une fusion manuelle depuis la AWS AppSync console ou via l'StartSchemaMergeopération disponible dans le AWS SDK et AWS l'interface de ligne de commande.

Support supplémentaire pour les API fusionnées

Configuration des abonnements

Contrairement aux approches basées sur les routeurs pour la composition de schémas GraphQL, les API AWS AppSync fusionnées fournissent un support intégré pour les abonnements GraphQL. Toutes les opérations d'abonnement définies dans vos API sources associées seront automatiquement fusionnées et fonctionneront dans votre API fusionnée sans modification. Pour en savoir plus sur la prise AWS AppSync en charge des abonnements via une WebSockets connexion sans serveur, consultez les Real-time données.

Configuration de l'observabilité

AWS AppSync Les API fusionnées fournissent une journalisation, une surveillance et des mesures intégrées via Amazon CloudWatch. AWS AppSync fournit également un support intégré pour le traçage via AWS X-Ray.

Configuration de domaines personnalisés

AWS AppSync Les API fusionnées fournissent un support intégré pour l'utilisation de domaines personnalisés avec GraphQL et les points de Real-time terminaison de votre API fusionnée.

Configuration de la mise en cache

AWS AppSync Les API fusionnées fournissent un support intégré pour éventuellement mettre en cache les réponses au niveau du and/or résolveur au niveau de la demande ainsi que pour la compression des réponses. Pour en savoir plus, consultez la section Mise en cache et compression.

Configuration d'API privées

AWS AppSync Les API fusionnées fournissent une prise en charge intégrée des API privées qui limitent l'accès à GraphQL et aux points de Real-time terminaison de votre API fusionnée au trafic provenant des points de terminaison VPC que vous pouvez configurer.

Configuration des règles de pare-feu

AWS AppSync Les API fusionnées fournissent un support intégré pour AWS WAF, ce qui vous permet de protéger vos API en définissant des règles de pare-feu pour les applications Web.

Configuration des journaux d'audit

AWS AppSync Les API fusionnées fournissent un support intégré pour AWS CloudTrail, ce qui vous permet de configurer et de gérer les journaux d'audit.

Limitations des API fusionnées

Lorsque vous développez des API fusionnées, tenez compte des règles suivantes :

Considérations relatives aux API fusionnées

Lors de la conception et de la mise en œuvre d'API fusionnées, tenez compte des points suivants :

La fusion de plusieurs API sources en un seul point de terminaison peut augmenter la taille et la complexité de votre schéma GraphQL et de vos requêtes. Au fur et à mesure que votre schéma fusionné se développe, les requêtes peuvent devoir passer par plusieurs résolveurs pour traiter une seule demande, ce qui peut augmenter la latence de votre temps de demande global. Par exemple, une requête qui accède à des champs provenant de plusieurs API sources peut nécessiter AWS AppSync l'exécution séquentielle des résolveurs de chaque API source, chaque résolveur augmentant le temps de réponse total.

Nous vous recommandons vivement de tester minutieusement vos API fusionnées pendant le développement et dans des conditions de charge réalistes afin de vous assurer qu'elles répondent aux exigences de votre entreprise. Portez une attention particulière à :

Envisagez de mettre en œuvre des optimisations de performances telles que la mise en cache, le traitement par lots des demandes de sources de données et la conception de vos schémas d'API source afin de minimiser le nombre d'exécutions de résolveurs requises pour les opérations courantes.

Création d'API fusionnées

Pour créer une API fusionnée dans la console