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 APIs AWS AppSync

Wenn der Einsatz von GraphQL innerhalb eines Unternehmens zunimmt, können Kompromisse zwischen API ease-of-use und der Geschwindigkeit der API Entwicklung entstehen. Einerseits setzen AWS AppSync Unternehmen GraphQL ein, um die Anwendungsentwicklung zu vereinfachen, indem sie Entwicklern eine flexible Lösung bieten, mit der API 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 API GraphQL-Endpunkt zusammengefasst sind, möglicherweise die Möglichkeit haben, API Updates unabhängig voneinander zu erstellen, zu verwalten und bereitzustellen, um ihre Entwicklungsgeschwindigkeit zu erhöhen.

Um dieses Problem zu lösen, ermöglicht die APIs Funktion AWS AppSync Zusammenführung es Teams aus verschiedenen Datendomänen, unabhängig voneinander zu erstellen und bereitzustellen AWS AppSync APIs (z. B. GraphQL-Schemas, Resolver, Datenquellen und Funktionen), die dann zu einem einzigen, zusammengeführten System kombiniert werden können. API Dies gibt Unternehmen die Möglichkeit, ein benutzerfreundliches, domänenübergreifendes System aufrechtzuerhalten und den verschiedenen TeamsAPI, die dazu beitragen, API die Möglichkeit zu geben, schnell und unabhängig Aktualisierungen vorzunehmen. API

Mithilfe von APIs Merged können Unternehmen die Ressourcen mehrerer, unabhängiger Quellen AWS AppSync APIs in einen einzigen AWS AppSync zusammengeführten API Endpunkt importieren. Zu diesem Zweck AWS AppSync können Sie eine Liste mit Quellquellen erstellen und anschließend alle mit der AWS AppSync Quelle verknüpften MetadatenAPIs, APIs einschließlich Schema, Typen, Datenquellen, Resolver und Funktionen, zu einem neuen zusammengeführten Datensatz zusammenführen. AWS AppSync API

Bei Zusammenführungen besteht die Möglichkeit, dass aufgrund von Inkonsistenzen im API Quelldateninhalt ein Zusammenführungskonflikt auftritt, z. B. aufgrund von Typbenennungskonflikten beim Kombinieren mehrerer Schemas. In einfachen Anwendungsfällen, in denen keine Definitionen in der Quelle miteinander in APIs Konflikt stehen, müssen die Quellschemas nicht geändert werden. API Das resultierende API Merged importiert einfach alle Typen, Resolver, Datenquellen und Funktionen aus der Originalquelle. AWS AppSync APIs Bei komplexen Anwendungsfällen, in denen Konflikte auftreten, müssen die Benutzer/Teams die Konflikte auf verschiedene Weise lösen. AWS AppSync stellt Benutzern verschiedene Tools und Beispiele zur Verfügung, mit denen Zusammenführungskonflikte reduziert werden können.

Bei nachfolgenden Zusammenführungen, die in konfiguriert sind, AWS AppSync werden die in der Quelle vorgenommenen Änderungen APIs auf die zugehörige Zusammenführung übertragen. API

Zusammengeführt APIs und Verbund

In der GraphQL-Community gibt es viele Lösungen und Muster, um GraphQL-Schemas zu kombinieren und die Teamzusammenarbeit über einen gemeinsamen Graphen zu ermöglichen. AWS AppSync Merged APIs verwendet bei der Schemakomposition einen Build-Time-Ansatz, bei dem die Quelldateien zu einem separaten, zusammengeführten Schema zusammengefasst APIs werden. API Ein alternativer Ansatz besteht darin, einen Runtime-Router über mehrere Quell APIs - oder Untergraphen 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 Anforderungselemente auf die zugrunde liegenden Subgraphen/Server. In der folgenden Tabelle wird der API Merged-Build-Time-Ansatz mit routerbasierten Laufzeitansätzen für die AWS AppSync GraphQL-Schemakomposition verglichen:

* AWS AppSync Zusammengeführt APIs kann nur mit der AWS AppSync Quelle verknüpft werdenAPIs. Wenn Sie Unterstützung für die Schemakomposition zwischen AWS AppSync und ohne AWS AppSync Unterdiagramme benötigen, können Sie ein oder mehrere AWS AppSync GraphQL und/oder Merged APIs zu einer routerbasierten Lösung verbinden. Im Referenz-Blog finden Sie beispielsweise Informationen zum Hinzufügen AWS AppSync APIs als Untergraph mithilfe einer routerbasierten Architektur mit Apollo Federation v2: Apollo GraphQL Federation with. AWS AppSync

Zusammengeführte Konfliktlösung API

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

Zusammengeführte API Schemaanweisungen

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

Sehen Sie sich das folgende Beispiel an, um zu zeigen, was die Utility-Schema-Direktiven bieten:

Gehen wir in diesem Beispiel davon aus, dass wir zwei Quellen zusammenführen möchtenAPIs. Wir erhalten zwei Schemas, mit denen Beiträge erstellt und abgerufen werden können (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 ein hohes Konfliktpotenzial. Die folgenden Ausschnitte zeigen die Typen und Felder der einzelnen Schemas.

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

# 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 namens 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 Source2.graphql auch mehrere Direktiven enthält, um diese Konflikte zu reduzieren. Der Post Typ ist mit einem @hidden -Tag versehen, um sich während des Zusammenführungsvorgangs selbst zu verschleiern. Der Message Typ ist mit dem @renamed -Tag versehen, in den der Typname geändert werden kann, falls es zu ChatMessage einem Namenskonflikt mit einem anderen Typ kommt. 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, ergibt 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 kommt auch vor, dass einem widersprüchlichen Typ keine Direktiven hinzugefügt wurden. Hier beinhaltet der zusammengeführte Typ die Vereinigung aller Felder aus allen Quelldefinitionen dieses Typs. Sehen Sie sich dazu das folgende Beispiel an:

Dieses Schema, Source1.graphQL genannt, ermöglicht das Erstellen und Abrufen. Posts 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 mit dem Namen Source2.graphql ermöglicht das Erstellen und Abrufen Reviews (z. B. Filmbewertungen oder Restaurantkritiken). Reviewssind mit demselben ID-Wert Post verknüpft. Zusammen enthalten sie den Titel, die Beitrags-ID und die Nutzdatennachricht des vollständigen Bewertungsbeitrags.

Beim Zusammenführen wird es zu einem Konflikt zwischen den beiden Post Typen kommen. Da es keine Anmerkungen zur Lösung dieses Problems gibt, besteht das Standardverhalten darin, eine Vereinigung der 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, ergibt 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 auf gemeinsam genutzten Typen

Stellen Sie sich im obigen Beispiel den Fall vor, dass Source1.graphql einen Unit-Resolver konfiguriert hatQuery.getPost, der eine DynamoDB-Datenquelle mit dem Namen verwendet. PostDatasource Dieser Resolver gibt das und eines Typs zurück. id title Post Stellen Sie sich nun vor, dass Source2.graphql einen Pipeline-Resolver konfiguriert hatPost.reviews, auf dem zwei Funktionen ausgeführt werden. Function1hat eine None Datenquelle angehängt, 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 API Merged-Endpunkt ausgeführt wird, führt der AWS AppSync Dienst zunächst den Unit-Resolver für Query.getPost from ausSource1, der DynamoDB aufruft PostDatasource und die Daten von DynamoDB zurückgibt. Anschließend führt er den Post.reviews Pipeline-Resolver aus, der Function1 eine benutzerdefinierte Autorisierungslogik ausführt und die Bewertungen Function2 zurückgibt, die in gefunden wurden. id $context.source Der Dienst verarbeitet die Anfrage als einen einzigen GraphQL-Lauf, und für diese einfache Anfrage ist nur ein einziges Anforderungstoken erforderlich.

Verwaltung von Konfliktlösern bei gemeinsam genutzten Typen

Stellen Sie sich den folgenden Fall vor, Query.getPost in dem wir auch einen Resolver auf implementieren, um mehrere Felder gleichzeitig bereitzustellen, die über den Feld-Resolver in hinausgehen. Source2 Source1.graphql kö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.graphql könnte 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 Merged APIs nicht zulässt, 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 Source2.graphql einen separaten Typ hinzufügen müsste, der die Felder, die es besitzt, vom Typ definiert. Post Im folgenden Beispiel fügen wir einen Typ namens hinzu, der die Inhalts- und Autorenfelder enthältPostInfo, die von Source2.graphql aufgelöst werden. Source1.graphql implementiert den an angehängten ResolverQuery.getPost, wohingegen Source2.graphql nun einen Resolver anhängt, um sicherzustellen, dass alle Daten erfolgreich abgerufen werden können: Post.postInfo

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 API Quellschemas neu geschrieben werden und die Clients möglicherweise ihre Abfragen ändern müssen. Der Vorteil dieses Ansatzes besteht jedoch darin, dass die Eigentümer der zusammengeführten Resolver für die Quellteams weiterhin klar sind.

Schemas konfigurieren

Zwei Parteien sind für die Konfiguration der Schemas verantwortlich, um ein zusammengeführtes Schema zu erstellen: API

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

Autorisierungsmodi konfigurieren

Zum Schutz Ihres Merged stehen mehrere Autorisierungsmodi zur VerfügungAPI. Weitere Informationen zu den Autorisierungsmodi finden Sie unter Autorisierung und Authentifizierung. AWS AppSync

Die folgenden Autorisierungsmodi stehen für Merged zur VerfügungAPIs:

Die Autorisierungsmodi einer Merged API werden vom API Eigentümer der Merged konfiguriert. Zum Zeitpunkt einer Zusammenführung API muss Merged den für eine Quelle konfigurierten primären Autorisierungsmodus enthalten, API entweder als eigener primärer Autorisierungsmodus oder als sekundärer Autorisierungsmodus. Andernfalls ist er inkompatibel und der Zusammenführungsvorgang schlägt aufgrund eines Konflikts fehl. Wenn Multi-Auth-Direktiven in der Quelle verwendet werdenAPIs, kann der Zusammenführungsprozess diese Direktiven automatisch mit dem vereinheitlichten Endpunkt zusammenführen. Falls der primäre Autorisierungsmodus der Quelle API nicht mit dem primären Autorisierungsmodus von Merged übereinstimmt, werden diese Authentifizierungsdirektiven automatisch hinzugefügtAPI, um sicherzustellen, dass der Autorisierungsmodus für die Typen in der Quelle konsistent ist. API

Konfiguration von Ausführungsrollen

Wenn Sie ein Merged erstellenAPI, müssen Sie eine Servicerolle definieren. Eine AWS Servicerolle ist eine AWS Identity and Access Management Zugriffsverwaltungsrolle (IAM), die von AWS Diensten verwendet wird, um Aufgaben in Ihrem Namen auszuführen.

In diesem Zusammenhang ist es erforderlich, dass Ihr Merged API Resolver ausführt, die auf Daten aus den in Ihrer Quelle APIs konfigurierten Datenquellen zugreifen. Die dafür erforderliche Servicerolle ist diemergedApiExecutionRole, und sie muss über expliziten Zugriff verfügen, um Anfragen auf der Quelle ausführen zu können, die in Ihrer Zusammenführung API über die appsync:SourceGraphQL IAM Berechtigung APIs enthalten ist. Während der Ausführung einer GraphQL-Anfrage übernimmt der AWS AppSync Dienst diese Dienstrolle und autorisiert die Rolle, die Aktion auszuführen. 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 funktioniert. IAM APIs Für non-top-level Felder AWS AppSync müssen Sie die Berechtigung für die Quelle API ARN selbst definieren. Um den Zugriff auf bestimmte non-top-level Felder im Merged einzuschränken, empfehlen wirAPI, eine benutzerdefinierte Logik in Ihrem Lambda zu implementieren oder die API Quellfelder API mithilfe der @hidden -Direktive vor dem Merged zu verbergen. Wenn Sie möchten, dass die Rolle alle Datenoperationen innerhalb einer Quelle ausführtAPI, 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 behandelt, die für die Quellressource API selbst autorisieren:

{
    "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 beschränken möchten, können Sie eine Richtlinie wie die folgende verwenden:

{
    "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 AWS AppSync API Konsolenerstellung verwenden, um eine Servicerolle zu generieren, mit der Ihr zusammengeführtes System API auf Ressourcen zugreifen kannAPIs, die in der Quelle konfiguriert sind und sich in demselben Konto wie Ihr API zusammengeführtes Konto befinden. Falls sich Ihre Quelle nicht in demselben Konto wie APIs Ihr zusammengeführtes Konto befindetAPI, müssen Sie Ihre Ressourcen zunächst mithilfe von AWS Resource Access Manager (AWS RAM) gemeinsam nutzen.

Konfiguration von kontoübergreifendem Zusammenführen mit APIs AWS RAM

Wenn Sie ein zusammengeführtes Konto erstellenAPI, können Sie optional Quellen APIs von anderen Konten zuordnen, 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 integriert sich AWS RAM in, um die Konfiguration und den Zugriff auf Quellen APIs über mehrere Konten hinweg von einem einzigen Merged aus zu unterstützenAPI. AWS RAM ermöglicht es Ihnen, eine gemeinsame Ressourcennutzung 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 hinzufügen in AWS RAM. AWS AppSync Stellt innerhalb einer Ressourcenfreigabe drei verschiedene Berechtigungssätze bereit, die mit einem AWS AppSync API in verknüpft werden könnenRAM:

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. Kundenverwaltete 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 zu wählen:

Sobald Sie eine Quelle ordnungsgemäß freigegeben API oder zusammengeführt API haben AWS RAM und gegebenenfalls die Einladung zur gemeinsamen Nutzung der Ressource akzeptiert wurde, wird sie in der AWS AppSync Konsole angezeigt, wenn Sie die API Quellenverknüpfungen in Ihrer Datei Zusammengeführt erstellen oder aktualisierenAPI. Sie können auch alle Dateien auflisten AWS AppSync APIs, die AWS RAM mit Ihrem Konto geteilt wurden, unabhängig vom jeweiligen Berechtigungssatz, indem Sie den von bereitgestellten ListGraphqlApis Vorgang aufrufen AWS AppSync und den OTHER_ACCOUNTS Besitzerfilter verwenden.

Zusammenführen

Zusammenführungen verwalten

Zusammengeführt APIs sollen die Teamzusammenarbeit auf einem einheitlichen AWS AppSync Endpunkt unterstützen. Teams können unabhängig voneinander ihre eigene isolierte GraphQL-Quelle APIs im Backend weiterentwickeln, während der AWS AppSync Service die Integration der Ressourcen in den einzigen zusammengeführten API Endpunkt verwaltet, um Reibungsverluste bei der Zusammenarbeit zu reduzieren und die Entwicklungsvorlaufzeiten zu verkürzen.

Automatische Zusammenführungen

Die mit Ihrer AWS AppSync Merged APIs verknüpfte Quelle API kann so konfiguriert werden, dass sie automatisch mit der Merged zusammengeführt wird, API nachdem Änderungen an der Quelle API vorgenommen wurden. Dadurch wird sichergestellt, dass die Änderungen aus der Quelle API immer an den zusammengeführten API Endpunkt im Hintergrund weitergegeben werden. Jede Änderung am API Quellschema wird in Merged aktualisiert, API sofern dadurch kein Mergekonflikt mit einer vorhandenen Definition in Merged entsteht. API Wenn das Update in der Quelle API einen Resolver, eine Datenquelle oder eine Funktion aktualisiert, wird auch die importierte Ressource aktualisiert. Wenn ein neuer Konflikt eingeführt wird, der nicht automatisch gelöst werden kann (automatisch gelöst), 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 API Quellzuordnung verfügbar, die den Status hat. MERGE_FAILED Sie können die Fehlermeldung auch überprüfen, indem Sie den GetSourceApiAssociation Vorgang für eine bestimmte API Quellzuweisung aufrufen, indem Sie den AWS SDK oder AWS CLI wie folgt verwenden:

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

Dies führt zu einem Ergebnis im folgenden Format:

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

Manuelle Zusammenführungen

Die Standardeinstellung für eine Quelle API ist eine manuelle Zusammenführung. Um alle Änderungen zusammenzuführen, die APIs seit der letzten Aktualisierung von Merged an der Quelle vorgenommen wurden, kann der API Quelleneigentümer eine manuelle Zusammenführung von der AWS AppSync Konsole aus oder über den unter AWS SDK und AWS CLI verfügbaren StartSchemaMerge Vorgang aufrufen. API

Zusätzliche Unterstützung für Merged APIs

Konfiguration von Abonnements

Im Gegensatz zu routerbasierten Ansätzen zur GraphQL-Schemakomposition bietet Merged AWS AppSync integrierte APIs Unterstützung für GraphQL-Abonnements. Alle Abonnementvorgänge, die in Ihrer zugehörigen Quelle definiert sind, APIs werden automatisch zusammengeführt und funktionieren in Ihrem Merged unverändert. API Weitere Informationen darüber, wie Abonnements über serverlose WebSockets Verbindungen AWS AppSync unterstützt werden, finden Sie unter Echtzeitdaten.

Beobachtbarkeit konfigurieren

AWS AppSync APIsMerged bietet integrierte Protokollierung, Überwachung und Metriken über Amazon CloudWatch. AWS AppSync bietet auch integrierte Unterstützung für die Rückverfolgung über AWS X-Ray.

Konfiguration benutzerdefinierter Domänen

AWS AppSync APIsMerged bietet integrierte Unterstützung für die Verwendung benutzerdefinierter Domains mit den GraphQL- und Echtzeit-Endpunkten API von Merged.

Caching konfigurieren

AWS AppSync APIsMerged bietet integrierte Unterstützung für das optionale Zwischenspeichern von Antworten auf Anfrage- und/oder Resolverebene sowie für die Antwortkomprimierung. Weitere Informationen finden Sie unter Zwischenspeichern und Komprimierung.

Private Konfiguration APIs

AWS AppSync APIsMerged bietet integrierte Unterstützung für PrivateAPIs, die den Zugriff auf die GraphQL- und Realtime-Endpunkte Ihres Merged auf Datenverkehr beschränkt, der von VPCEndpunkten stammt, die Sie konfigurieren können. API

Konfiguration von Firewall-Regeln

AWS AppSync APIsMerged bietet integrierte Unterstützung für AWS WAF, sodass Sie Ihre Daten schützen können, APIs indem Sie Firewall-Regeln für Webanwendungen definieren.

Konfiguration von Audit-Logs

AWS AppSync APIsMerged bietet integrierte Unterstützung für AWS CloudTrail, mit der Sie Auditprotokolle konfigurieren und verwalten können.

Zusammengeführte API Einschränkungen

Beachten Sie bei der APIs Entwicklung von Merged die folgenden Regeln:

Zusammengeführt erstellen APIs

Um ein Merged API in der Konsole zu erstellen