Fusion dans APIs AWS AppSync

Au fur et à mesure que l'utilisation de GraphQL se développe au sein d'une organisation, des compromis peuvent survenir entre la rapidité API du développement API ease-of-use et sa rapidité. D'une part, les entreprises adoptent AWS AppSync GraphQL pour simplifier le développement d'applications en offrant aux développeurs une flexibilité API leur permettant d'accéder, de manipuler et de 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 en un seul point de API terminaison GraphQL peuvent souhaiter pouvoir créer, gérer et déployer des API mises à jour indépendamment les unes des autres afin d'augmenter leurs vitesses de développement.

Pour résoudre cette tension, la APIs fonctionnalité AWS AppSync Merged permet aux équipes issues de différents domaines de données de créer et de déployer indépendamment AWS AppSync APIs (par exemple, des schémas GraphQL, des résolveurs, des sources de données et des fonctions), qui peuvent ensuite être combinés en un seul fichier fusionné. API Cela permet aux entreprises de maintenir une solution multidomaine API simple à utiliser et permet aux différentes équipes qui y contribuent d'effectuer API des API mises à jour rapidement et de manière indépendante.

Grâce à MergedAPIs, les organisations peuvent importer les ressources de plusieurs sources indépendantes AWS AppSync APIs dans un seul point de API terminaison AWS AppSync Merged. Pour ce faire, vous AWS AppSync permet de créer une liste de sources sources AWS AppSync APIs, puis de fusionner toutes les métadonnées associées à la source, APIs y compris le schéma, les types, les sources de données, les résolveurs et les fonctions, dans une nouvelle AWS AppSync fusion. API

Lors des fusions, il est possible qu'un conflit de fusion se produise en raison d'incohérences dans le contenu des API données sources, 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 de la source n'est en APIs conflit, il n'est pas nécessaire de modifier les API schémas source. Le Merged qui en résulte importe API simplement tous les types, résolveurs, sources de données et fonctions à partir de la source AWS AppSync APIs d'origine. Pour les cas d'utilisation complexes où des conflits surviennent, les utilisateurs/équipes 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 répercuteront les modifications apportées dans la source APIs vers le Merged associé. API

Fusion APIs et fédération

La communauté GraphQL propose de nombreuses solutions et modèles permettant de combiner des schémas GraphQL et de permettre la collaboration d'équipe via un graphe partagé. AWS AppSync Merged APIs adopte une approche basée sur le temps de construction pour la composition du schéma, dans laquelle APIs les sources sont combinées dans une version séparée, MergedAPI. Une autre approche consiste à superposer un routeur d'exécution sur plusieurs sources APIs ou sous-graphes. Dans cette approche, le routeur reçoit une demande, 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 sur ses sous-graphiques/serveurs sous-jacents. Le tableau suivant compare l'approche AWS AppSync Merged API Build-time avec les approches d'exécution basées sur un routeur pour la composition de schémas GraphQL :

Fonctionnalité	AppSync Fusionné API	Solutions basées sur des routeurs
Sous-graphes gérés de manière indépendante	Oui	Oui
Sous-graphes adressables indépendamment	Oui	Oui
Composition de schéma automatisée	Oui	Oui
Détection automatique des conflits	Oui	Oui
Résolution des conflits par le biais de directives de schéma	Oui	Oui
Serveurs de sous-graphes pris en charge	AWS AppSync*	Varie
Complexité du réseau	Unique et fusionné, API cela signifie qu'il n'y a pas de sauts de réseau supplémentaires.	L'architecture multicouche nécessite la planification et la délégation des requêtes, l'analyse et la sérialisation/désérialisation des sous-requêtes, ainsi que des résolveurs de référence dans les sous-graphes pour effectuer des jointures.
Soutien à l'observabilité	Surveillance, journalisation et suivi intégrés. Un API serveur unique et fusionné permet un débogage simplifié.	Build-your-own observabilité sur le routeur et tous les serveurs de sous-graphes associés. Débogage complexe sur un système distribué.
Assistance en matière d'autorisation	Prise en charge intégrée de plusieurs modes d'autorisation.	Build-your-own règles d'autorisation.
Sécurité entre comptes	Support intégré pour les associations de comptes AWS multicloud.	Build-your-own modèle de sécurité.
Support pour les abonnements	Oui	Non

* La AWS AppSync fusion ne APIs peut être associée qu'à AWS AppSync la sourceAPIs. Si vous avez besoin de support pour la composition de schémas entre AWS AppSync et sans AWS AppSync sous-graphes, vous pouvez connecter un ou plusieurs AWS AppSync GraphQL et/ou APIs Merged à une solution basée sur un routeur. Par exemple, consultez le blog de référence pour l'ajouter en AWS AppSync APIs tant que sous-graphe à l'aide d'une architecture basée sur un routeur avec Apollo Federation v2 : Apollo GraphQL Federation with. AWS AppSync

Résolution des API conflits fusionnée

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 API de schéma fusionnées

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

• @canonical : Cette directive définit la priorité des types/champs ayant des noms et des données similaires. Si deux sources ou plus APIs ont le même type ou champ GraphQL, l'une d'entre elles APIs peut annoter son type ou son champ comme étant canonique, ce qui sera priorisé lors de la fusion. Les types/champs en conflit qui ne sont pas annotés avec cette directive dans une autre source APIs sont ignorés lors de la fusion.

• @hidden : Cette directive encapsule certains types/champs pour les supprimer du processus de fusion. Les équipes peuvent souhaiter supprimer ou masquer des types ou des opérations spécifiques dans la source API afin que seuls les clients internes puissent accéder à des données saisies spécifiques. Avec cette directive attachée, les types ou les champs ne sont pas fusionnés dans le MergedAPI.

• @renamed : Cette directive modifie les noms des types/champs afin de réduire les conflits de dénomination. Il existe des situations où différents APIs ont le même type ou le même nom de champ. Cependant, ils doivent tous être disponibles dans le schéma fusionné. Un moyen simple de les inclure tous dans le Merged API est de renommer le champ en quelque chose de similaire mais différent.

Pour illustrer le schéma utilitaire fourni par les directives, considérez l'exemple suivant :

Dans cet exemple, supposons que nous voulons fusionner deux sourcesAPIs. Deux schémas nous ont été fournis pour créer et récupérer des publications (par exemple, une section de commentaires ou des publications sur les réseaux sociaux). En supposant que les types et les champs sont très similaires, le risque de conflit est élevé lors d'une opération de fusion. Les extraits ci-dessous indiquent 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'aide de la mutation. Posts putPost Chacune Post contient un titre et un identifiant. L'identifiant est utilisé pour faire référence aux User informations ou à celles de l'auteur (e-mail et adresse)Message, et à la charge utile (contenu). Le User type est annoté avec 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, des conflits de fusion peuvent survenir en raison de ces différences.

Notez également que Source2.graphQL contient également plusieurs directives pour réduire ces conflits. Le Post type est annoté avec une balise @hidden pour se masquer pendant 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 aura lieu, 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 événements se sont produits lors de la fusion :

• Le User type de Source1.graphQL a été prioritaire par rapport à celui de Source2.graphQL en User raison de l'annotation @canonical.

• Le Message type de Source1.graphQL a été inclus dans la fusion. Cependant, le fichier Message from Source2.graphql présentait un conflit de dénomination. En raison de son annotation @renamed, il a également été inclus dans la fusion mais avec un autre nomChatMessage.

• Le Post type de Source1.graphql a été inclus, mais pas le Post type de Source2.graphql. Normalement, il y aurait un conflit sur ce type, mais comme le Post type de Source2.graphQL comportait une annotation @hidden, ses données ont été masquées et n'ont pas été incluses dans la fusion. Cela n'a entraîné aucun conflit.

• Le Query type a été mis à jour pour inclure le contenu des deux fichiers. Cependant, une GetMessage requête a été renommée en GetChatMessage raison de la directive. Cela a résolu le conflit de dénomination entre les deux requêtes portant le même nom.

Il y a aussi 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érer. Posts La configuration est similaire à celle de 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'ID. Ensemble, ils contiennent le titre, l'ID de publication et le message de charge utile de l'article de critique complet.

Lors de la fusion, il y aura un conflit entre les deux Post types. Aucune annotation ne permettant 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 aura lieu, 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 événements se sont produits lors de la fusion :

• Le Mutation type n'a rencontré aucun conflit et a été fusionné.

• Les champs Post de type ont été combinés via une opération syndicale. Remarquez comment l'union entre les deux a produit un single idtitle, un a et un singlereviews.

• Le Review type n'a rencontré aucun conflit et a été fusionné.

• Le Query type n'a rencontré aucun conflit et a été fusionné.

Gestion des résolveurs sur des types partagés

Dans l'exemple ci-dessus, considérez le cas où Source1.graphQL a configuré un résolveur d'unités surQuery.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 que Source2.graphQL a configuré un résolveur de pipeline sur lequel s'exécutent Post.reviews deux fonctions. Function1possède une source None de données attachée pour effectuer des contrôles d'autorisation personnalisés. Function2possède une source de données DynamoDB attachée pour interroger la table. reviews

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

Lorsque la requête ci-dessus est exécutée par un client sur le point de API terminaison Merged, 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 qui Function1 exécute une logique d'autorisation personnalisée et Function2 renvoie les avis en $context.source fonction de ce qui s'y id trouve. Le service traite la demande comme une seule exécution de GraphQL, et cette demande simple 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.graphQL peut 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.graphQL peut 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 AWS AppSync Merged APIs n'autorise pas l'association de 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 obligerait Source2.graphQL à ajouter un type distinct qui définira les champs qu'il possède par rapport au type. Post 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.graphql implémentera le résolveur attaché àQuery.getPost, tandis que Source2.graphql associera désormais un résolveur pour garantir que toutes les données peuvent être récupérées avec Post.postInfo 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 API schémas sources et, éventuellement, la modification des requêtes par les clients, l'avantage de cette approche est que les équipes sources restent clairement propriétaires des résolveurs fusionnés.

Configuration des schémas

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

• APIPropriétaires fusionnés - API Les propriétaires fusionnés doivent configurer la logique d'autorisation API du fusionné et les paramètres avancés tels que la journalisation, le suivi, la mise en cache et le WAF support.

• APIPropriétaires de source associés : API les propriétaires associés doivent configurer les schémas, les résolveurs et les sources de données qui constituent le Merged. API

Comme le schéma API de votre Merged est créé à partir des schémas de votre source associéeAPIs, il est en lecture seule. Cela signifie que les modifications du schéma doivent être initiées dans votre sourceAPIs. Dans la AWS AppSync console, vous pouvez basculer entre votre schéma Merged et les schémas individuels de la source APIs inclus dans votre Merged à l'APIaide 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 MergedAPI. 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 Merged APIs :

• APIclé : la stratégie d'autorisation la plus simple. Toutes les demandes doivent inclure une API clé sous l'en-tête de la x-api-key demande. Les API clés expirées sont conservées pendant 60 jours après la date d'expiration.

• AWS Identity and Access Management (IAM) : La stratégie AWS IAM d'autorisation autorise toutes les demandes signées sigv4.

• Groupes d'utilisateurs Amazon Cognito : autorisez vos utilisateurs via les groupes d'utilisateurs Amazon Cognito pour obtenir un contrôle plus précis.

• AWS Autorisateurs Lambda : fonction sans serveur qui vous permet de vous authentifier et d'autoriser l'accès à votre compte à l'aide d'une logique personnalisée. AWS AppSync API

• OpenID Connect : ce type d'autorisation applique les jetons OpenID connect OIDC () fournis par un service conforme. OIDC Votre application peut tirer parti des utilisateurs et des privilèges définis par votre OIDC fournisseur pour contrôler l'accès.

Les modes d'autorisation d'une fusion API sont configurés par le API propriétaire de la fusion. Au moment d'une opération de fusion, la fusion API doit inclure le mode d'autorisation principal configuré sur une source, API soit en tant que mode d'autorisation principal, soit en tant que mode d'autorisation secondaire. Dans le cas contraire, elle sera incompatible et l'opération de fusion échouera en raison d'un conflit. Lorsque vous utilisez des directives multi-auth dans la sourceAPIs, le processus de fusion est capable de fusionner automatiquement ces directives dans le point de terminaison unifié. Dans le cas où le mode d'autorisation principal de la source API ne correspond pas au mode d'autorisation principal du MergedAPI, il ajoutera automatiquement ces directives d'authentification pour garantir que le mode d'autorisation pour les types de la source API est cohérent.

Configuration des rôles d'exécution

Lorsque vous créez une fusionAPI, vous devez définir un rôle de service. Un rôle de AWS service est un rôle AWS Identity and Access Management (IAM) utilisé par les AWS services pour effectuer des tâches en votre nom.

Dans ce contexte, il est nécessaire que votre Merged API exécute des résolveurs qui accèdent aux données à partir des sources de données configurées dans votre sourceAPIs. Le rôle de service requis pour cela est lemergedApiExecutionRole, et il doit avoir un accès explicite pour exécuter des demandes sur la source APIs incluse dans votre fusion API via l'appsync:SourceGraphQLIAMautorisation. Lors de l'exécution d'une requête GraphQL, le AWS AppSync service assumera ce rôle de service et autorisera le rôle à effectuer l'appsync:SourceGraphQLaction.

AWS AppSync permet d'autoriser ou de refuser cette autorisation sur des champs de haut niveau spécifiques de la demande, comme le fonctionnement du mode IAM d'autorisation. IAM APIs Pour non-top-level les champs AWS AppSync , vous devez définir l'autorisation sur la source API ARN elle-même. Afin de restreindre l'accès à des non-top-level champs spécifiques dans le MergedAPI, nous vous recommandons d'implémenter une logique personnalisée dans votre Lambda ou de masquer les API champs source dans le Merged à l'APIaide de la directive @hidden. Si vous souhaitez autoriser le rôle à effectuer toutes les opérations de données au sein d'une sourceAPI, 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 seconde entrée couvre les résolveurs enfants qui autorisent la API ressource source elle-même :

{
    "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 :

{
    "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 API création de AWS AppSync console pour générer un rôle de service afin de permettre à votre Merged d'accéder API aux ressources configurées dans le code source APIs qui se trouvent dans le même compte que celui que vous avez fusionnéAPI. Dans le cas où votre source APIs ne figure pas dans le même compte que celui que vous avez fusionnéAPI, vous devez d'abord partager vos ressources à l'aide de AWS Resource Access Manager (AWS RAM).

Configuration de plusieurs comptes fusionnés APIs à l'aide de AWS RAM

Lorsque vous créez un MergedAPI, vous pouvez éventuellement associer une source APIs provenant d'autres comptes 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 (OUs), ainsi qu'avec IAM les rôles et les utilisateurs.

AWS AppSync s'intègre afin de prendre AWS RAM en charge la configuration et l'accès à la source APIs sur plusieurs comptes à partir d'un seul MergedAPI. 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 chacun d'entre eux. Vous pouvez ajouter AWS AppSync APIs à une ressource partagée dans AWS RAM. Dans un partage de ressources, AWS AppSync fournit trois ensembles d'autorisations différents qui peuvent être associés à un AWS AppSync API in RAM :

1. AWSRAMPermissionAppSyncSourceApiOperationAccess: ensemble d'autorisations par défaut ajouté lors du partage d'une AWS AppSync API entrée AWS RAM si aucune autre autorisation n'est spécifiée. Cet ensemble d'autorisations est utilisé pour partager une source AWS AppSync API avec un API propriétaire fusionné. Cet ensemble d'autorisations inclut l'autorisation pour appsync:AssociateMergedGraphqlApi la source API ainsi que l'appsync:SourceGraphQLautorisation requise pour accéder aux API ressources source lors de l'exécution.

2. AWSRAMPermissionAppSyncMergedApiOperationAccess: Cet ensemble d'autorisations doit être configuré lors du partage d'une fusion API avec le API propriétaire d'une source. Cet ensemble d'autorisations donnera à la source API la possibilité de configurer le Merged, API y compris la possibilité d'associer toute source APIs appartenant au principal cible au Merged et de lire API et de mettre à jour les API associations de sources du MergedAPI.

3. AWSRAMPermissionAppSyncAllowSourceGraphQLAccess: Cet ensemble d'autorisations permet appsync:SourceGraphQL d'utiliser l'autorisation avec un AWS AppSync API. Il est destiné à être utilisé pour partager une source API avec un API propriétaire fusionné. Contrairement à l'ensemble d'autorisations par défaut pour l'accès aux API opérations source, cet ensemble d'autorisations inclut uniquement l'autorisation d'exécutionappsync:SourceGraphQL. Si un utilisateur choisit de partager l'accès à l'APIopération fusionnée avec un API propriétaire de source, il devra également partager cette autorisation de la source API avec le API propriétaire fusionné afin de disposer d'un accès à l'exécution via le point de API terminaison fusionné.

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. Les autorisations gérées par le client sont des autorisations gérées que vous créez et gérez en spécifiant précisément quelles actions peuvent être effectuées et dans quelles conditions avec des ressources partagées. AWS RAM AWS AppSync vous permet de choisir parmi les actions suivantes lors de la création de votre propre autorisation :

1. appsync:AssociateSourceGraphqlApi

2. appsync:AssociateMergedGraphqlApi

3. appsync:GetSourceApiAssociation

4. appsync:UpdateSourceApiAssociation

5. appsync:StartSchemaMerge

6. appsync:ListTypesByAssociation

7. appsync:SourceGraphQL

Une fois que vous avez correctement partagé une source API ou que vous l'avez fusionnée API AWS RAM et que, si nécessaire, l'invitation au partage de ressources a été acceptée, elle sera visible dans la AWS AppSync console lorsque vous créerez ou mettrez à jour les API associations de sources sur votre MergedAPI. Vous pouvez également répertorier tout AWS AppSync APIs ce qui a été partagé 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.

Note

Le partage via AWS RAM nécessite que l'appelant soit autorisé à effectuer l'appsync:PutResourcePolicyaction sur tout API ce qui est partagé. AWS RAM

Fusion

Gestion des fusions

APIsLes solutions fusionnées sont destinées à favoriser la collaboration en équipe sur un point de AWS AppSync terminaison unifié. Les équipes peuvent faire évoluer indépendamment leur propre source GraphQL isolée APIs dans le backend tandis que le AWS AppSync service gère l'intégration des ressources dans le point de API terminaison unique Merged afin de réduire les frictions dans la collaboration et de réduire les délais de développement.

Fusions automatiques

La source APIs associée à votre AWS AppSync API Merged peut être configurée pour fusionner automatiquement (fusion automatique) dans le Merged une API fois que des modifications ont été apportées à la sourceAPI. Cela garantit que les modifications depuis la source API sont toujours propagées vers le point de API terminaison fusionné en arrière-plan. Toute modification du API schéma source sera mise à jour dans le Merged API tant qu'elle n'introduit pas de conflit de fusion avec une définition existante dans le MergedAPI. Si la mise à jour dans la source API 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 API schéma fusionné 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 API association source dont le statut estMERGE_FAILED. Vous pouvez également inspecter le message d'erreur en appelant l'GetSourceApiAssociationopération pour une API association de source donnée en utilisant le AWS SDK ou en utilisant une AWS CLI méthode similaire :

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 pour une source API est une fusion manuelle. Pour fusionner les modifications apportées à la source APIs depuis la dernière mise à jour de Merged, le API propriétaire de la source peut invoquer une fusion manuelle depuis la AWS AppSync console ou via l'StartSchemaMergeopération disponible dans le AWS SDK et AWS CLI. API

Support supplémentaire pour Merged APIs

Configuration des abonnements

Contrairement aux approches basées sur les routeurs pour la composition de schémas GraphQL, AWS AppSync Merged APIs fournit un support intégré pour les abonnements GraphQL. Toutes les opérations d'abonnement définies dans votre source associée APIs seront automatiquement fusionnées et fonctionneront dans votre API Merged sans modification. Pour en savoir plus sur la prise AWS AppSync en charge des abonnements via une WebSockets connexion sans serveur, consultez la section Données en temps réel.

Configuration de l'observabilité

AWS AppSync Merged APIs fournit des fonctionnalités intégrées de journalisation, de surveillance et de statistiques 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 Merged APIs fournit un support intégré pour l'utilisation de domaines personnalisés avec le GraphQL de votre Merged et les points API de terminaison en temps réel.

Configuration de la mise en cache

AWS AppSync Merged APIs fournit un support intégré pour la mise en cache facultative des réponses au niveau de la demande et/ou au niveau du résolveur, ainsi que pour la compression des réponses. Pour en savoir plus, consultez la section Mise en cache et compression.

Configuration du mode privé APIs

AWS AppSync Merged APIs fournit un support intégré pour le mode privé APIs qui limite l'accès au GraphQL API de votre Merged et aux points de terminaison en temps réel au trafic provenant de points de VPCterminaison que vous pouvez configurer.

Configuration des règles de pare-feu

AWS AppSync Merged APIs fournit un support intégré qui vous permet de vous protéger APIs en définissant des règles de pare-feu pour les applications Web. AWS WAF

Configuration des journaux d'audit

AWS AppSync Merged APIs fournit un support intégré qui vous permet de configurer et de gérer les journaux d'audit. AWS CloudTrail

APILimitations fusionnées

Lorsque vous développez APIs Merged, prenez note des règles suivantes :

1. Un Merged API ne peut pas être la source API d'un autre MergedAPI.

2. Une source API ne peut pas être associée à plusieurs MergedAPI.

3. La limite de taille par défaut pour un document de API schéma fusionné est de 10 Mo.

4. Le nombre par défaut de sources APIs pouvant être associées à une fusion API est de 10. Cependant, vous pouvez demander une augmentation de limite si vous avez besoin de plus de 10 sources APIs dans votre MergedAPI.

Création d'une fusion APIs

Pour créer un Merged API dans la console

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

   1. Dans le tableau de bord, choisissez Create API.

2. Choisissez Fusionné API, puis Next.

3. Dans la page Spécifier API les détails, entrez les informations suivantes :

   1. Sous APIDétails, entrez les informations suivantes :

      1. Spécifiez le APInom API de votre fusionné. Ce champ permet d'étiqueter votre GraphQL API afin de le distinguer facilement des autres GraphQL. APIs

      2. Spécifiez les détails du contact. Ce champ est facultatif et attache un nom ou un groupe au GraphQLAPI. Il n'est pas lié ou généré par d'autres ressources et fonctionne de la même manière que le champ de API nom.

   2. Sous Rôle de service, vous devez associer un rôle IAM d'exécution à votre fusion API afin de AWS AppSync pouvoir importer et utiliser vos ressources en toute sécurité lors de l'exécution. Vous pouvez choisir de créer et d'utiliser un nouveau rôle de service, qui vous permettra de spécifier les politiques et les AWS AppSync ressources à utiliser. Vous pouvez également importer un IAM rôle existant en choisissant Utiliser un rôle de service existant, puis en sélectionnant le rôle dans la liste déroulante.

   3. Sous APIConfiguration privée, vous pouvez choisir d'activer les API fonctionnalités privées. Notez que ce choix ne peut pas être modifié après avoir créé la fusionAPI. Pour plus d'informations sur le mode privéAPIs, consultez la section Utilisation du AWS AppSync mode privé APIs.

      Choisissez Next une fois que vous avez terminé.

4. Ensuite, vous devez ajouter le GraphQL APIs qui servira de base à votre fusion. API Dans la APIs page Sélectionner la source, entrez les informations suivantes :

   1. Dans le tableau APIsà partir de votre AWS compte, sélectionnez Ajouter une source APIs. Dans la liste de GraphQLAPIs, chaque entrée contiendra les données suivantes :

      1. Nom : champ de APInom de GraphQLAPI.

      2. APIID : valeur d'ID unique API de GraphQL.

      3. Mode d'authentification principal : mode d'autorisation par défaut pour API GraphQL. Pour plus d'informations sur les modes d'autorisation dans AWS AppSync, consultez la section Autorisation et authentification.

      4. Mode d'authentification supplémentaire : modes d'autorisation secondaires configurés dans GraphQL. API

      5. Choisissez celui APIs que vous utiliserez dans la fusion API en cochant la case à côté API du champ Nom. Ensuite, choisissez Ajouter une source APIs. Le GraphQL sélectionné APIs apparaîtra dans le tableau APIsdepuis vos AWS comptes.

   2. Dans le tableau APIsprovenant d'autres AWS comptes, choisissez Ajouter une source APIs. Les GraphQL APIs de cette liste proviennent d'autres comptes qui partagent leurs ressources avec les vôtres via AWS Resource Access Manager ()AWS RAM. Le processus de sélection de GraphQL APIs dans ce tableau est le même que celui de la section précédente. Pour plus d'informations sur le partage de ressources via AWS RAM, voir Qu'est-ce que c'est AWS Resource Access Manager ? .

      Choisissez Next une fois que vous avez terminé.

   3. Ajoutez votre mode d'authentification principal. Voir Autorisation et authentification pour plus d'informations. Choisissez Suivant.

   4. Passez en revue vos entrées, puis choisissez Créer API.