Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Zusammenführen von APIs in AWS AppSync

Wenn die Verwendung von GraphQL innerhalb eines Unternehmens zunimmt, können Kompromisse zwischen der Benutzerfreundlichkeit der API und der Geschwindigkeit der API-Entwicklung entstehen. Einerseits verwenden AWS AppSync Unternehmen GraphQL, um die Anwendungsentwicklung zu vereinfachen. Dies gibt Entwicklern eine flexible API, mit der sie mit einem einzigen Netzwerkaufruf sicher auf Daten aus einer oder mehreren Datendomänen zugreifen, diese bearbeiten und kombinieren können. Andererseits möchten Teams innerhalb einer Organisation, die für die verschiedenen Datendomänen verantwortlich sind, die zu einem einzigen GraphQL-API-Endpunkt zusammengefasst sind, möglicherweise die Möglichkeit, API-Updates unabhängig voneinander zu erstellen, zu verwalten und bereitzustellen. Dies erhöht ihre Entwicklungsgeschwindigkeit.

Um diese Spannung zu lösen, ermöglicht die Funktion „ AWS AppSync Zusammengeführte APIs“ Teams aus verschiedenen Datendomänen, unabhängig voneinander AWS AppSync APIs (z. B. GraphQL-Schemas, Resolver, Datenquellen und Funktionen) zu erstellen und bereitzustellen, die dann zu einer einzigen, zusammengeführten API kombiniert werden können. Dies gibt Unternehmen die Möglichkeit, eine einfach zu verwendende, domänenübergreifende API zu verwalten, und den verschiedenen Teams, die zu dieser API beitragen, die Möglichkeit, API-Updates schnell und unabhängig voneinander vorzunehmen.

Das folgende Diagramm zeigt den zusammengeführten API-Workflow:

Mithilfe zusammengeführter APIs können Unternehmen die Ressourcen mehrerer unabhängiger AWS AppSync Quell-APIs in einen einzigen AWS AppSync zusammengeführten API-Endpunkt importieren. Zu diesem Zweck AWS AppSync können Sie eine Liste von AWS AppSync Quell-APIs erstellen und dann alle mit den Quell-APIs verknüpften Metadaten, einschließlich Schema, Typen, Datenquellen, Resolver und Funktionen, in einer neuen AWS AppSync zusammengeführten API zusammenführen.

Bei Zusammenführungen besteht die Möglichkeit, dass ein Zusammenführungskonflikt aufgrund von Inkonsistenzen im Quell-API-Dateninhalt auftritt, z. B. aufgrund von Typbenennungskonflikten beim Kombinieren mehrerer Schemas. Für einfache Anwendungsfälle, in denen keine Definitionen in den Quell-APIs in Konflikt geraten, müssen die Quell-API-Schemas nicht geändert werden. Die daraus resultierende zusammengeführte API importiert einfach alle Typen, Resolver, Datenquellen und Funktionen aus den ursprünglichen AWS AppSync Quell-APIs. Bei komplexen Anwendungsfällen, in denen Konflikte auftreten, users/teams müssen die Konflikte auf verschiedene Weise gelöst werden. AWS AppSync stellt Benutzern verschiedene Tools und Beispiele zur Verfügung, mit denen Merge-Konflikte reduziert werden können.

Nachfolgende Zusammenführungen, die in konfiguriert sind, übertragen Änderungen, AWS AppSync die an den Quell-APIs vorgenommen wurden, an die zugehörige Merge-API.

Zusammengeführte APIs und Verbund

In der GraphQL-Community gibt es viele Lösungen und Muster, um GraphQL-Schemas zu kombinieren und die Teamzusammenarbeit über ein gemeinsames Diagramm zu ermöglichen. AWS AppSync Zusammengeführte APIs verfolgen bei der Schemakomposition einen Build-Time-Ansatz, bei dem Quell-APIs zu einer separaten, zusammengeführten API kombiniert werden. Ein alternativer Ansatz besteht darin, einen Runtime-Router über mehrere Quell-APIs oder Unterdiagramme zu verteilen. Bei diesem Ansatz empfängt der Router eine Anfrage, verweist auf ein kombiniertes Schema, das er als Metadaten verwaltet, erstellt einen Anforderungsplan und verteilt dann die Anforderungselemente auf die zugrunde liegenden Sub-. graphs/servers In der folgenden Tabelle wird der Build-Time-Ansatz AWS AppSync der Merged-API mit routerbasierten Laufzeitansätzen für die GraphQL-Schemakomposition verglichen:

* AWS AppSync Zusammengeführte APIs können nur AWS AppSync Quell-APIs zugeordnet werden. Wenn Sie Unterstützung für die Schemakomposition zwischen AWS AppSync und ohne AWS AppSync Unterdiagramme benötigen, können Sie eine oder mehrere AWS AppSync GraphQL and/or Merged-APIs zu einer routerbasierten Lösung verbinden. Im Referenzblog finden Sie beispielsweise Informationen zum Hinzufügen von AWS AppSync APIs als Unterdiagramm unter Verwendung einer routerbasierten Architektur mit Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync

Zusammengeführte API-Konfliktlösung

AWS AppSync Stellt Benutzern im Falle eines Zusammenführungskonflikts mehrere Tools und Beispiele zur Verfügung, um die Probleme zu beheben.

Richtlinien für zusammengeführte API-Schemas

AWS AppSync hat mehrere GraphQL-Direktiven eingeführt, die verwendet werden können, um Konflikte zwischen Quell-APIs zu reduzieren oder zu lösen:

Sehen Sie sich das folgende Beispiel an, um zu zeigen, welche Hilfsprogramme Schemadirektiven bieten:

Gehen wir in diesem Beispiel davon aus, dass wir zwei Quell-APIs zusammenführen möchten. Wir erhalten zwei Schemas, mit denen Beiträge erstellt und abgerufen werden (z. B. Kommentarbereich oder Beiträge in sozialen Netzwerken). Unter der Annahme, dass sich die Typen und Felder sehr ähnlich sind, besteht bei einer Zusammenführung eine hohe Wahrscheinlichkeit von Konflikten. Die folgenden Ausschnitte zeigen die Typen und Felder der einzelnen Schemas.

Die erste Datei, genannt Source1.graphql, ist ein GraphQL-Schema, das es einem Benutzer ermöglicht, Posts mithilfe der Mutation etwas zu erstellen. putPost Jede Post enthält einen Titel und eine ID. Die ID wird verwendetUser, um auf die Informationen des Posters (E-Mail-Adresse und Adresse) und auf die Message Nutzdaten (Inhalt) zu verweisen. Der User Typ ist mit dem @canonical -Tag versehen.

# 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
}

Die zweite Datei, genannt Source2.graphql, ist ein GraphQL-Schema, das sehr ähnliche Dinge tut wie. Source1.graphql Beachten Sie jedoch, dass die Felder der einzelnen Typen unterschiedlich sind. Beim Zusammenführen dieser beiden Schemas kommt es aufgrund dieser Unterschiede zu Zusammenführungskonflikten.

Beachten Sie auch, dass how Source2.graphql auch mehrere Anweisungen zur Reduzierung dieser Konflikte enthält. Der Post Typ ist mit einem @hidden -Tag versehen, um sich während des Zusammenführungsvorgangs zu verschleiern. Der Message Typ ist mit dem @renamed -Tag versehen, sodass der Typname im Falle eines Namenskonflikts mit einem anderen Typ ChatMessage in geändert werden kann. Message

# 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")
}

Wenn die Zusammenführung erfolgt, erzeugt das Ergebnis die folgende MergedSchema.graphql Datei:

# 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
}

Bei der Zusammenführung sind mehrere Dinge passiert:

Es gibt auch den Fall, dass einem widersprüchlichen Typ keine Direktiven hinzugefügt werden. In diesem Fall beinhaltet der zusammengeführte Typ die Vereinigung aller Felder aus allen Quelldefinitionen dieses Typs. Sehen Sie sich dazu das folgende Beispiel an:

Dieses Schema, genannt Source1.graphql, ermöglicht das Erstellen und AbrufenPosts. Die Konfiguration ähnelt dem vorherigen Beispiel, enthält jedoch weniger Informationen.

# 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
}

Dieses Schema, genannt Source2.graphql, ermöglicht das Erstellen und Abrufen Reviews (z. B. von Filmbewertungen oder Restaurantkritiken). Reviewssind mit demselben Post ID-Wert verknüpft. Zusammen enthalten sie den Titel, die Beitrags-ID und die Nutzlastnachricht des vollständigen Rezensionsbeitrags.

Beim Zusammenführen wird es einen Konflikt zwischen den beiden Post Typen geben. Da es keine Anmerkungen gibt, um dieses Problem zu lösen, besteht das Standardverhalten darin, einen Vereinigungsvorgang für die widersprüchlichen Typen durchzuführen.

# 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
}

Wenn die Zusammenführung erfolgt, erzeugt das Ergebnis die folgende Datei: MergedSchema.graphql

# 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
}

Bei der Zusammenführung sind mehrere Dinge passiert:

Verwaltung von Resolvern für gemeinsam genutzte Typen

Stellen Sie sich im obigen Beispiel den Fall vor, dass ein Unit-Resolver konfiguriert Source1.graphql wurdeQuery.getPost, der eine DynamoDB-Datenquelle mit dem Namen verwendet. PostDatasource Dieser Resolver gibt das Ende eines Typs id zurück. title Post Consider Source2.graphql hat nun einen Pipeline-Resolver konfiguriertPost.reviews, auf dem zwei Funktionen ausgeführt werden. Function1hat eine angefügte None Datenquelle, um benutzerdefinierte Autorisierungsprüfungen durchzuführen. Function2hat eine DynamoDB-Datenquelle angehängt, um die reviews Tabelle abzufragen.

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

Wenn die obige Abfrage von einem Client für den Merged-API-Endpunkt ausgeführt wird, führt der AWS AppSync Dienst zuerst den Unit-Resolver für Query.getPost from ausSource1, der DynamoDB aufruft PostDatasource und die Daten von DynamoDB zurückgibt. Dann führt er den Post.reviews Pipeline-Resolver Function1 aus, in dem die benutzerdefinierte Autorisierungslogik ausgeführt wird und die Function2 eingegebenen Bewertungen zurückgegeben werden. id $context.source Der Dienst verarbeitet die Anfrage als einzelne GraphQL-Ausführung, und für diese einfache Anfrage ist nur ein einziges Anforderungstoken erforderlich.

Verwaltung von Resolver-Konflikten bei gemeinsam genutzten Typen

Stellen Sie sich den folgenden Fall vor, Query.getPost in dem wir auch einen Resolver implementieren, um über den Feld-Resolver hinaus mehrere Felder gleichzeitig bereitzustellen. Source2 Source1.graphqlkönnte so aussehen:

# This snippet represents a file called Source1.graphql

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

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

Source2.graphqlkann so aussehen:

# This snippet represents a file called Source2.graphql

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

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

Der Versuch, diese beiden Schemas zusammenzuführen, führt zu einem Zusammenführungsfehler, da AWS AppSync zusammengeführte APIs nicht zulassen, dass mehrere Quell-Resolver an dasselbe Feld angehängt werden. Um diesen Konflikt zu lösen, können Sie ein Feldauflösungsmuster implementieren, bei dem ein separater Typ Source2.graphql hinzugefügt werden müsste, der die Felder, die ihm gehören, von dem Typ unterscheidet. Post Im folgenden Beispiel fügen wir einen Typ mit dem Namen hinzuPostInfo, der die Inhalts- und Autorenfelder enthält, die aufgelöst werden Source2.graphql. Source1.graphqlimplementiert den Resolver, an den er angehängt istQuery.getPost, und Source2.graphql fügt nun einen Resolver hinzu, Post.postInfo um sicherzustellen, dass alle Daten erfolgreich abgerufen werden können:

type Post  {
  id: ID!
  postInfo: PostInfo
}

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

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

Die Lösung eines solchen Konflikts erfordert zwar, dass die Quell-API-Schemas neu geschrieben werden und Kunden möglicherweise ihre Abfragen ändern müssen. Der Vorteil dieses Ansatzes besteht jedoch darin, dass die Eigentümer der zusammengeführten Resolver allen Quellteams klar sind.

Verwaltung der Autorisierung für gemeinsam genutzte Felder

Wenn zwei oder mehr Quell-APIs dasselbe Feld deklarieren, werden bei der Zusammenführung die Autorisierungsrichtlinien aus jeder Deklaration kombiniert. Clients können das zusammengeführte Feld dann über einen dieser Autorisierungsmodi erreichen. Wenn eine Quell-API ein Feld mit deklariert @aws_iam und eine andere Quell-API dasselbe Feld mit deklariert@aws_api_key, akzeptiert das zusammengeführte Feld beides, und ein Client, der nur einen API-Schlüssel besitzt, kann es aufrufen.

Um die Autorisierung eines Felds so beizubehalten, wie sie von Ihrer Quell-API definiert wird, kommentieren Sie das Feld mit @canonical und deklarieren Sie die Autorisierungsdirektive, die Sie benötigen, für das Feld selbst. Im folgenden Beispiel Source1.graphql besitzt er den Resolver für protectedRead und benötigt eine IAM-Autorisierung:

# 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
}

Bei der Zusammenführung hat die Definition von Source1.graphql Vorrang:

# This snippet represents a file called MergedSchema.graphql

type Query {
    protectedRead: String @aws_iam
}

Ohne die @canonical -Annotation wäre das zusammengeführte Feld wie folgtprotectedRead: String @aws_api_key @aws_iam: Ein Client, der nur den API-Schlüssel der zusammengeführten API besitzt, kann ihn dann aufrufen.

Wenn Ihre Quell-API den Resolver des Felds besitzt, kommentieren Sie das Feld in dieser Quell-API mit Anmerkungen, da der Resolver die Daten zurückgibt.

Es gelten zwei Bedingungen:

Deklarieren Sie die Autorisierungsrichtlinie für das Feld

@canonical behält das deklarierte Feld bei. Ein mit @canonical annotiertes Feld ohne eigene Autorisierungsdirektive verwendet den primären Autorisierungsmodus Ihrer Quell-API, der möglicherweise freizügiger ist, als Sie beabsichtigen.

Kommentieren Sie ein Feld in nur einer Quell-API

Wenn zwei Quell-APIs dasselbe Feld mit Canonical annotieren, schlägt die Zusammenführung mit dem Fehler fehl. Multiple subschemas cannot declare the same field as canonical

Wenden Sie @canonical auf Feldebene und nicht auf Typebene an, um die Autorisierung auf bestimmte Felder einzuschränken. Dadurch können andere Quell-APIs immer noch zusätzliche Felder desselben Typs hinzufügen. Diese Anleitung gilt für Felder mit und Subscription sowie für Felder mit Objekttypen. Query Mutation

Wenn Sie nicht möchten, dass ein Feld in der Merged-API überhaupt erscheint, verwenden Sie stattdessen @hidden. Weitere Informationen finden Sie unter Richtlinien für zusammengeführte API-Schemas.

Schemas konfigurieren

Zwei Parteien sind für die Konfiguration der Schemas zur Erstellung einer zusammengeführten API verantwortlich:

Da das Schema Ihrer zusammengeführten API aus den Schemas Ihrer verknüpften Quell-APIs erstellt wird, ist es schreibgeschützt. Das bedeutet, dass Änderungen am Schema in Ihren Quell-APIs initiiert werden müssen. In der AWS AppSync Konsole können Sie mithilfe der Dropdownliste über dem Schemafenster zwischen Ihrem zusammengeführten Schema und den einzelnen Schemas der Quell-APIs, die in Ihrer zusammengeführten API enthalten sind, wechseln.

Konfiguration der Autorisierungsmodi

Zum Schutz Ihrer zusammengeführten API stehen mehrere Autorisierungsmodi zur Verfügung. Weitere Informationen zu den Autorisierungsmodi finden Sie unter Autorisierung und Authentifizierung. AWS AppSync

Die folgenden Autorisierungsmodi stehen für die Verwendung mit zusammengeführten APIs zur Verfügung:

Die Autorisierungsmodi einer zusammengeführten API werden vom Eigentümer der zusammengeführten API konfiguriert. Zum Zeitpunkt eines Zusammenführungsvorgangs muss die zusammengeführte API den primären Autorisierungsmodus enthalten, der auf einer Quell-API entweder als eigenen primären Autorisierungsmodus oder als sekundären Autorisierungsmodus konfiguriert ist. Andernfalls ist es inkompatibel und der Zusammenführungsvorgang schlägt aufgrund eines Konflikts fehl. Wenn Multiauth-Direktiven in den Quell-APIs verwendet werden, kann der Zusammenführungsprozess diese Direktiven automatisch zum einheitlichen Endpunkt zusammenführen. Falls der primäre Autorisierungsmodus der Quell-API nicht mit dem primären Autorisierungsmodus der zusammengeführten API übereinstimmt, werden diese Authentifizierungsdirektiven automatisch hinzugefügt, um sicherzustellen, dass der Autorisierungsmodus für die Typen in der Quell-API konsistent ist.

Ausführungsrollen konfigurieren

Wenn Sie eine zusammengeführte API erstellen, müssen Sie eine Servicerolle definieren. Eine AWS Servicerolle ist eine AWS Identity and Access Management (IAM) -Rolle, die von AWS Diensten verwendet wird, um Aufgaben in Ihrem Namen auszuführen.

In diesem Zusammenhang ist es erforderlich, dass Ihre Merged-API Resolver ausführt, die auf Daten aus den in Ihren Quell-APIs konfigurierten Datenquellen zugreifen. Die dafür erforderliche Servicerolle ist diemergedApiExecutionRole, und sie muss über die appsync:SourceGraphQL IAM-Berechtigung expliziten Zugriff haben, um Anfragen für Quell-APIs auszuführen, die in Ihrer zusammengeführten API enthalten sind. Während der Ausführung einer GraphQL-Anfrage übernimmt der AWS AppSync Dienst diese Servicerolle und autorisiert die Rolle zur Ausführung der Aktion. appsync:SourceGraphQL

AWS AppSync unterstützt das Zulassen oder Verweigern dieser Berechtigung für bestimmte Felder der obersten Ebene innerhalb der Anfrage, z. B. wie der IAM-Autorisierungsmodus für IAM-APIs funktioniert. Für Felder, die nicht auf oberster Ebene AWS AppSync sind, müssen Sie die Berechtigung für den Quell-API-ARN selbst definieren. Um den Zugriff auf bestimmte Felder in der Merged-API einzuschränken, die nicht auf oberster Ebene liegen, empfehlen wir, eine benutzerdefinierte Logik in Ihrem Lambda zu implementieren oder die Quell-API-Felder mithilfe der @hidden -Direktive vor der Merged-API auszublenden. Wenn Sie der Rolle erlauben möchten, alle Datenoperationen innerhalb einer Quell-API auszuführen, können Sie die folgende Richtlinie hinzufügen. Beachten Sie, dass der erste Ressourceneintrag den Zugriff auf alle Felder der obersten Ebene ermöglicht und der zweite Eintrag untergeordnete Resolver abdeckt, die auf der Quell-API-Ressource selbst autorisieren:

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"] 
    }] 
}

Wenn Sie den Zugriff nur auf ein bestimmtes Feld der obersten Ebene einschränken möchten, können Sie eine Richtlinie wie diese verwenden:

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"] 
    }] 
}

Sie können auch den Assistenten zur Erstellung von AWS AppSync Konsolen-APIs verwenden, um eine Servicerolle zu generieren, mit der Ihre zusammengeführte API auf Ressourcen zugreifen kann, die in Quell-APIs konfiguriert sind und sich im selben Konto wie Ihre zusammengeführte API befinden. Falls sich Ihre Quell-APIs nicht im selben Konto wie Ihre zusammengeführte API befinden, müssen Sie Ihre Ressourcen zunächst mithilfe von AWS Resource Access Manager (AWS RAM) gemeinsam nutzen.

Konfiguration kontoübergreifender zusammengeführter APIs mit AWS RAM

Wenn Sie eine zusammengeführte API erstellen, können Sie optional Quell-APIs von anderen Konten verknüpfen, die über AWS Resource Access Manager (AWS RAM) gemeinsam genutzt wurden. AWS RAM hilft Ihnen dabei, Ihre Ressourcen sicher zwischen AWS Konten, innerhalb Ihrer Organisation oder Organisationseinheiten (OUs) sowie mit IAM-Rollen und -Benutzern gemeinsam zu nutzen.

AWS AppSync lässt sich AWS RAM in integrieren, um die Konfiguration und den Zugriff auf Quell-APIs für mehrere Konten über eine einzige zusammengeführte API zu unterstützen. AWS RAM ermöglicht es Ihnen, eine gemeinsame Nutzung von Ressourcen oder einen Container mit Ressourcen und den Berechtigungssätzen zu erstellen, die für jede Ressource gemeinsam genutzt werden. Sie können AWS AppSync APIs zu einer Ressourcenfreigabe in hinzufügen AWS RAM. AWS AppSync Stellt innerhalb einer Ressourcenfreigabe drei verschiedene Berechtigungssätze bereit, die einer AWS AppSync API im RAM zugeordnet werden können:

AWS AppSync unterstützt auch vom Kunden verwaltete Berechtigungen. Wenn eine der bereitgestellten AWS verwalteten Berechtigungen nicht funktioniert, können Sie Ihre eigene, vom Kunden verwaltete Berechtigung erstellen. Customer-managed Berechtigungen sind verwaltete Berechtigungen, die Sie erstellen und verwalten, indem Sie genau angeben, welche Aktionen unter welchen Bedingungen mit gemeinsam genutzten Ressourcen ausgeführt werden können. AWS RAM AWS AppSync ermöglicht es Ihnen, bei der Erstellung Ihrer eigenen Berechtigungen aus den folgenden Aktionen auszuwählen:

Sobald Sie eine Quell-API oder Merged-API ordnungsgemäß freigegeben AWS RAM und, falls erforderlich, die Einladung zur gemeinsamen Nutzung von Ressourcen akzeptiert haben, wird sie in der AWS AppSync Konsole angezeigt, wenn Sie die Quell-API-Verknüpfungen in Ihrer zusammengeführten API erstellen oder aktualisieren. Sie können auch alle AWS AppSync APIs auflisten, die AWS RAM mit Ihrem Konto gemeinsam genutzt wurden, unabhängig von der eingestellten Berechtigung, indem Sie den von Ihnen bereitgestellten ListGraphqlApis Vorgang aufrufen AWS AppSync und den OTHER_ACCOUNTS Eigentümerfilter verwenden.

Zusammenführen

Zusammenführungen verwalten

Zusammengeführte APIs sollen die Teamzusammenarbeit an einem einheitlichen AWS AppSync Endpunkt unterstützen. Teams können unabhängig voneinander ihre eigenen GraphQL-APIs aus isolierten Quellen im Backend entwickeln, während der AWS AppSync Service die Integration der Ressourcen in den einzigen Merged-API-Endpunkt verwaltet, um die Reibung bei der Zusammenarbeit zu verringern und die Entwicklungsvorlaufzeiten zu verkürzen.

Auto-merges

Quell-APIs, die Ihrer AWS AppSync Merged-API zugeordnet sind, können so konfiguriert werden, dass sie automatisch mit der Merged-API zusammengeführt werden (automatische Zusammenführung), nachdem Änderungen an der Quell-API vorgenommen wurden. Dadurch wird sichergestellt, dass die Änderungen an der Quell-API immer im Hintergrund an den Merged-API-Endpunkt weitergegeben werden. Jede Änderung des Quell-API-Schemas wird in der zusammengeführten API aktualisiert, sofern dadurch kein Zusammenführungskonflikt mit einer vorhandenen Definition in der zusammengeführten API entsteht. Wenn das Update in der Quell-API einen Resolver, eine Datenquelle oder eine Funktion aktualisiert, wird auch die importierte Ressource aktualisiert. Wenn ein neuer Konflikt auftritt, der nicht automatisch gelöst (automatisch gelöst) werden kann, wird die Aktualisierung des zusammengeführten API-Schemas aufgrund eines nicht unterstützten Konflikts während des Zusammenführungsvorgangs abgelehnt. Die Fehlermeldung ist in der Konsole für jede Quell-API-Zuordnung mit dem Status verfügbar. MERGE_FAILED Sie können die Fehlermeldung auch überprüfen, indem Sie den GetSourceApiAssociation Vorgang für eine bestimmte Quell-API-Zuordnung mithilfe des AWS SDK oder der AWS CLI wie folgt aufrufen:

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

Dadurch wird ein Ergebnis im folgenden Format erzeugt:

{
    "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."
    }
}

Manuelles Zusammenführen

Die Standardeinstellung für eine Quell-API ist eine manuelle Zusammenführung. Um alle Änderungen zusammenzuführen, die seit der letzten Aktualisierung der zusammengeführten API an den Quell-APIs vorgenommen wurden, kann der Eigentümer der Quell-API eine manuelle Zusammenführung über die AWS AppSync Konsole oder über den im AWS SDK und in der AWS CLI verfügbaren StartSchemaMerge Vorgang aufrufen.

Zusätzliche Unterstützung für zusammengeführte APIs

Abonnements konfigurieren

Im Gegensatz zu routerbasierten Ansätzen zur Erstellung von GraphQL-Schemas bieten AWS AppSync Merged-APIs integrierte Unterstützung für GraphQL-Abonnements. Alle Abonnementvorgänge, die in Ihren zugehörigen Quell-APIs definiert sind, werden automatisch zusammengeführt und funktionieren in Ihrer zusammengeführten API ohne Änderungen. Weitere Informationen darüber, wie Abonnements über serverlose WebSockets Verbindungen AWS AppSync unterstützt werden, finden Sie unter Real-time Daten.

Beobachtbarkeit konfigurieren

AWS AppSync Zusammengeführte APIs bieten integrierte Protokollierung, Überwachung und Metriken über Amazon CloudWatch. AWS AppSync bietet auch integrierte Unterstützung für Tracing über AWS X-Ray.

Konfiguration benutzerdefinierter Domänen

AWS AppSync Zusammengeführte APIs bieten integrierte Unterstützung für die Verwendung benutzerdefinierter Domänen mit GraphQL und Real-time Endpunkten Ihrer Merged-API.

Caching konfigurieren

AWS AppSync Zusammengeführte APIs bieten integrierte Unterstützung für das optionale Zwischenspeichern von Antworten auf and/or Resolverebene auf Anforderungsebene sowie für die Antwortkomprimierung. Weitere Informationen finden Sie unter Caching und Komprimierung. https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html

Konfiguration von privaten APIs

AWS AppSync Zusammengeführte APIs bieten integrierte Unterstützung für private APIs, die den Zugriff auf GraphQL und Real-time Endpunkte Ihrer Merged-API auf den Datenverkehr beschränken, der von VPC-Endpunkten stammt, die Sie konfigurieren können.

Konfiguration der Firewallregeln

AWS AppSync Zusammengeführte APIs bieten integrierte Unterstützung für AWS WAF, mit der Sie Ihre APIs schützen können, indem Sie Firewallregeln für Webanwendungen definieren.

Konfiguration von Auditprotokollen

AWS AppSync Zusammengeführte APIs bieten integrierte Unterstützung für AWS CloudTrail, mit der Sie Auditprotokolle konfigurieren und verwalten können.

Einschränkungen bei der Zusammenführung von APIs

Beachten Sie bei der Entwicklung zusammengeführter APIs die folgenden Regeln:

Überlegungen zur Zusammenführung der APIs

Beachten Sie beim Entwerfen und Implementieren zusammengeführter APIs Folgendes:

Das Zusammenführen mehrerer Quell-APIs zu einem einzigen Endpunkt kann die Größe und Komplexität Ihres GraphQL-Schemas und Ihrer Abfragen erhöhen. Wenn Ihr zusammengeführtes Schema wächst, müssen Abfragen möglicherweise mehrere Resolver durchlaufen, um eine einzelne Anfrage zu erfüllen, was Ihre gesamte Anforderungszeit verlängern kann. Beispielsweise kann es bei einer Abfrage, die auf Felder mehrerer Quell-APIs zugreift, erforderlich sein AWS AppSync , die Resolver von jeder Quell-API nacheinander auszuführen, wobei jeder Resolver die gesamte Antwortzeit erhöht.

Wir empfehlen Ihnen dringend, Ihre zusammengeführten APIs während der Entwicklung und unter realistischen Lastbedingungen gründlich zu testen, um sicherzustellen, dass sie Ihren Geschäftsanforderungen entsprechen. Achten Sie besonders auf:

Erwägen Sie die Implementierung von Leistungsoptimierungen wie Caching, Stapeln von Datenquellenanforderungen und das Entwerfen Ihrer Quell-API-Schemas, um die Anzahl der Resolver-Ausführungen zu minimieren, die für allgemeine Operationen erforderlich sind.

Zusammengeführte APIs erstellen

Um eine zusammengeführte API in der Konsole zu erstellen