

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.

# GraphQL APIs entwerfen mit AWS AppSync
<a name="designing-a-graphql-api"></a>

AWS AppSync ermöglicht es Ihnen, GraphQL APIs mithilfe der Konsolenerfahrung zu erstellen. Einen Eindruck davon haben Sie im Abschnitt [Ein Beispielschema starten](https://docs.aws.amazon.com/appsync/latest/devguide/quickstart.html) bekommen. In diesem Handbuch wurde jedoch nicht der gesamte Katalog der Optionen und Konfigurationen aufgeführt, die Sie nutzen könnten. AWS AppSync

Wenn Sie sich dafür entscheiden, eine GraphQL-API in der Konsole zu erstellen, stehen Ihnen mehrere Optionen zur Verfügung. Wenn Sie unseren Leitfaden zur [Einführung eines Beispielschemas](https://docs.aws.amazon.com/appsync/latest/devguide/quickstart.html) befolgt haben, haben wir Ihnen gezeigt, wie Sie eine API aus einem vordefinierten Modell erstellen. In den folgenden Abschnitten führen wir Sie durch die restlichen Optionen und Konfigurationen für die Erstellung von GraphQL APIs in AWS AppSync.

In diesem Abschnitt werden Sie sich mit den folgenden Konzepten befassen:

1. [Blank APIs or imports](blank-import-api.md#aws-appsync-blank-import-api): In diesem Handbuch wird der gesamte Erstellungsprozess für die Erstellung einer GraphQL-API beschrieben. Sie erfahren, wie Sie ein GraphQL aus einer leeren Vorlage ohne Modell erstellen, Datenquellen für Ihr Schema konfigurieren und Ihren ersten Resolver zu einem Feld hinzufügen.

1. [Real-time data](aws-appsync-real-time-data.md#aws-appsync-real-time-data-anchor): Diese Anleitung zeigt Ihnen die möglichen Optionen für die Erstellung einer API mithilfe AWS AppSync der WebSocket Engine.

1. [Merged APIs](merged-api.md#aws-appsync-merged-api): Diese Anleitung zeigt Ihnen, wie Sie neues GraphQL erstellen, APIs indem Sie Daten aus mehreren vorhandenen GraphQL verknüpfen und zusammenführen. APIs

1. [GraphQL APIs mit RDS-Introspektion erstellen](rds-introspection.md): Diese Anleitung zeigt Ihnen, wie Sie Ihre Amazon RDS-Tabellen mithilfe einer Daten-API integrieren.

# Strukturierung einer GraphQL-API (leer oder importiert APIs)
<a name="blank-import-api"></a>

Bevor Sie Ihre GraphQL-API aus einer leeren Vorlage erstellen, wäre es hilfreich, die Konzepte rund um GraphQL zu überprüfen. Es gibt drei grundlegende Komponenten einer GraphQL-API:

1. Das **Schema** ist die Datei, die die Form und Definition Ihrer Daten enthält. Wenn ein Client eine Anfrage an Ihren GraphQL-Dienst stellt, folgen die zurückgegebenen Daten der Spezifikation des Schemas. Weitere Informationen finden Sie unter [GraphQL-Schemas](schema-components.md#aws-appsync-schema-components).

1. Die **Datenquelle** ist an Ihr Schema angehängt. Wenn eine Anfrage gestellt wird, werden die Daten hier abgerufen und geändert. Weitere Informationen finden Sie unter [Datenquellen](data-source-components.md#aws-appsync-data-source-components).

1. Der **Resolver** befindet sich zwischen dem Schema und der Datenquelle. Wenn eine Anfrage gestellt wird, führt der Resolver den Vorgang mit den Daten aus der Quelle aus und gibt dann das Ergebnis als Antwort zurück. Weitere Informationen finden Sie unter [Resolver](resolver-components.md#aws-appsync-resolver-components).

![\[GraphQL API architecture showing schema, resolvers, and data sources connected via AppSync.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/appsync-architecture-graphql-api.png)


AWS AppSync verwaltet Ihre, APIs indem es Ihnen ermöglicht, den Code für Ihre Schemas und Resolver zu erstellen, zu bearbeiten und zu speichern. Ihre Datenquellen stammen aus externen Repositorys wie Datenbanken, DynamoDB-Tabellen und Lambda-Funktionen. Wenn Sie einen AWS Dienst zum Speichern Ihrer Daten verwenden oder dies planen, AWS AppSync bietet es eine nahezu nahtlose Erfahrung beim Zuordnen von Daten aus Ihren AWS Konten zu Ihrem GraphQL. APIs

Im nächsten Abschnitt erfahren Sie, wie Sie jede dieser Komponenten mithilfe des Dienstes erstellen. AWS AppSync 

**Topics**
+ [Entwerfen Ihres GraphQL-Schemas](designing-your-schema.md)
+ [Eine Datenquelle anhängen](attaching-a-data-source.md)
+ [Resolver konfigurieren AWS AppSync](resolver-config-overview.md)
+ [Verwendung APIs mit dem CDK](using-your-api.md)

# Entwerfen Ihres GraphQL-Schemas
<a name="designing-your-schema"></a>

Das GraphQL-Schema ist die Grundlage jeder GraphQL-Serverimplementierung. Jede GraphQL-API wird durch ein **einzelnes** Schema definiert, das Typen und Felder enthält, die beschreiben, wie die Daten aus Anfragen gefüllt werden. Die Daten, die durch Ihre API fließen, und die ausgeführten Operationen müssen anhand des Schemas validiert werden.

Im Allgemeinen beschreibt das [GraphQL-Typsystem](https://graphql.org/learn/schema/#type-system) die Funktionen eines GraphQL-Servers und wird verwendet, um festzustellen, ob eine Abfrage gültig ist. Das Typsystem eines Servers wird oft als das Schema dieses Servers bezeichnet und kann aus verschiedenen Objekttypen, Skalartypen, Eingabetypen und mehr bestehen. GraphQL ist sowohl deklarativ als auch stark typisiert, was bedeutet, dass die Typen zur Laufzeit gut definiert sind und nur das zurückgeben, was angegeben wurde.

AWS AppSync ermöglicht es Ihnen, GraphQL-Schemas zu definieren und zu konfigurieren. Der folgende Abschnitt beschreibt, wie Sie GraphQL-Schemas mithilfe AWS AppSync der Dienste von Grund auf neu erstellen.

## Strukturierung eines GraphQL-Schemas
<a name="schema-structure"></a>

**Tipp**  
Wir empfehlen, den Abschnitt [Schemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html) zu lesen, bevor Sie fortfahren.

GraphQL ist ein leistungsstarkes Tool zur Implementierung von API-Diensten. Laut der [Website von GraphQL ist](https://graphql.org/) GraphQL wie folgt:

„*GraphQL ist eine Abfragesprache APIs und eine Laufzeit für die Ausführung dieser Abfragen mit Ihren vorhandenen Daten. GraphQL bietet eine vollständige und verständliche Beschreibung der Daten in Ihrer API, gibt Kunden die Möglichkeit, genau nach dem zu fragen, was sie benötigen, und nicht mehr, erleichtert die Weiterentwicklung APIs im Laufe der Zeit und ermöglicht leistungsstarke Entwicklertools.* “

Dieser Abschnitt behandelt den allerersten Teil Ihrer GraphQL-Implementierung, das Schema. Unter Verwendung des obigen Zitats spielt ein Schema die Rolle, „eine vollständige und verständliche Beschreibung der Daten in Ihrer API bereitzustellen“. Mit anderen Worten, ein GraphQL-Schema ist eine textuelle Darstellung der Daten, Operationen und der Beziehungen zwischen ihnen Ihres Dienstes. Das Schema gilt als Haupteinstiegspunkt für Ihre GraphQL-Serviceimplementierung. Es überrascht nicht, dass es oft eines der ersten Dinge ist, die Sie in Ihrem Projekt machen. Wir empfehlen, den Abschnitt [Schemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html) zu lesen, bevor Sie fortfahren.

Um den Abschnitt [Schemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html) zu zitieren: GraphQL-Schemas sind in der *Schema Definition Language* (SDL) geschrieben. SDL besteht aus Typen und Feldern mit einer festgelegten Struktur:
+ **Typen**: Mit Typen definiert GraphQL die Form und das Verhalten der Daten. GraphQL unterstützt eine Vielzahl von Typen, die später in diesem Abschnitt erklärt werden. Jeder Typ, der in Ihrem Schema definiert ist, enthält seinen eigenen Bereich. Innerhalb des Bereichs befinden sich ein oder mehrere Felder, die einen Wert oder eine Logik enthalten können, die in Ihrem GraphQL-Dienst verwendet werden. Typen erfüllen viele verschiedene Rollen, am häufigsten sind Objekte oder Skalare (primitive Werttypen).
+ **Felder**: Felder existieren innerhalb des Gültigkeitsbereichs eines Typs und enthalten den Wert, der vom GraphQL-Dienst angefordert wird. Diese sind Variablen in anderen Programmiersprachen sehr ähnlich. Die Form der Daten, die Sie in Ihren Feldern definieren, bestimmt, wie die Daten in einer request/response Operation strukturiert werden. Auf diese Weise können Entwickler vorhersagen, was zurückgegeben wird, ohne zu wissen, wie das Backend des Dienstes implementiert ist.

Die einfachsten Schemas werden drei verschiedene Datenkategorien enthalten:

1. **Schemastämme**: Stammverzeichnisse definieren die Einstiegspunkte Ihres Schemas. Es verweist auf die Felder, die bestimmte Operationen an den Daten ausführen, z. B. etwas hinzufügen, löschen oder ändern.

1. **Typen**: Dies sind Basistypen, die verwendet werden, um die Form der Daten darzustellen. Man kann sich diese fast als Objekte oder abstrakte Repräsentationen von etwas mit definierten Eigenschaften vorstellen. Sie könnten beispielsweise ein `Person` Objekt erstellen, das eine Person in einer Datenbank darstellt. Die Eigenschaften jeder Person werden in den `Person` AS-Feldern definiert. Sie können alles Mögliche wie Name, Alter, Beruf, Adresse usw. der Person sein.

1. **Spezielle Objekttypen**: Dies sind die Typen, die das Verhalten der Operationen in Ihrem Schema definieren. Jeder spezielle Objekttyp wird einmal pro Schema definiert. Sie werden zuerst im Schemastamm platziert und dann im Hauptteil des Schemas definiert. Jedes Feld in einem speziellen Objekttyp definiert eine einzelne Operation, die von Ihrem Resolver implementiert werden soll.

Um das ins rechte Licht zu rücken, stellen Sie sich vor, Sie erstellen einen Dienst, der Autoren und die von ihnen geschriebenen Bücher speichert. Jeder Autor hat einen Namen und eine Reihe von Büchern, die er verfasst hat. Jedes Buch hat einen Namen und eine Liste der assoziierten Autoren. Wir möchten auch die Möglichkeit haben, Bücher und Autoren hinzuzufügen oder abzurufen. Eine einfache UML-Darstellung dieser Beziehung könnte wie folgt aussehen:

![\[UML diagram showing Author and Book classes with attributes and methods, linked by association.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/GraphQL-UML-1.png)


In GraphQL stellen die Entitäten `Author` und zwei verschiedene Objekttypen in Ihrem Schema `Book` dar:

```
type Author {
}

type Book {
}
```

`Author`enthält `authorName` und`Books`, während es `bookName` und `Book` `Authors` enthält. Diese können als Felder im Rahmen Ihrer Typen dargestellt werden:

```
type Author {
  authorName: String
  Books: [Book]
}

type Book {
  bookName: String
  Authors: [Author]
}
```

Wie Sie sehen können, sind die Typdarstellungen dem Diagramm sehr ähnlich. Bei den Methoden wird es jedoch etwas schwieriger. Diese werden als Feld in einem von wenigen speziellen Objekttypen platziert. Ihre spezielle Objektkategorisierung hängt von ihrem Verhalten ab. GraphQL enthält drei grundlegende spezielle Objekttypen: Abfragen, Mutationen und Abonnements. Weitere Informationen finden Sie unter [Spezielle Objekte](https://docs.aws.amazon.com//appsync/latest/devguide/graphql-types.html#special-object-components).

Da `getAuthor` beide Daten anfordern, werden sie einem `Query` speziellen Objekttyp zugeordnet: `getBook`

```
type Author {
  authorName: String
  Books: [Book]
}

type Book {
  bookName: String
  Authors: [Author]
}

type Query {
  getAuthor(authorName: String): Author
  getBook(bookName: String): Book
}
```

Die Operationen sind mit der Abfrage verknüpft, die wiederum mit dem Schema verknüpft ist. Wenn Sie einen Schemastamm hinzufügen, wird der spezielle Objekttyp (`Query`in diesem Fall) als einer Ihrer Einstiegspunkte definiert. Dies kann mit dem `schema` Schlüsselwort geschehen:

```
schema {
  query: Query
}

type Author {
  authorName: String
  Books: [Book]
}

type Book {
  bookName: String
  Authors: [Author]
}

type Query {
  getAuthor(authorName: String): Author
  getBook(bookName: String): Book
}
```

Schauen Sie sich die letzten beiden Methoden an `addAuthor` und `addBook` fügen Ihrer Datenbank Daten hinzu, sodass sie in einem `Mutation` speziellen Objekttyp definiert werden. Aus der Seite „[Typen](https://docs.aws.amazon.com/appsync/latest/devguide/graphql-types.html#input-components)“ wissen wir jedoch auch, dass Eingaben, die direkt auf Objekte verweisen, nicht zulässig sind, da es sich ausschließlich um Ausgabetypen handelt. In diesem Fall können wir `Author` oder nicht verwenden`Book`, also müssen wir einen Eingabetyp mit denselben Feldern erstellen. In diesem Beispiel haben wir `AuthorInput` und hinzugefügt`BookInput`, die beide dieselben Felder ihres jeweiligen Typs akzeptieren. Dann erstellen wir unsere Mutation mit den Eingaben als Parameter:

```
schema {
  query: Query
  mutation: Mutation
}

type Author {
  authorName: String
  Books: [Book]
}

input AuthorInput {
  authorName: String
  Books: [BookInput]
}

type Book {
  bookName: String
  Authors: [Author]
}

input BookInput {
  bookName: String
  Authors: [AuthorInput]
}

type Query {
  getAuthor(authorName: String): Author
  getBook(bookName: String): Book
}

type Mutation {
  addAuthor(input: [BookInput]): Author
  addBook(input: [AuthorInput]): Book
}
```

Lassen Sie uns überprüfen, was wir gerade getan haben:

1. Wir haben ein Schema mit den `Author` Typen `Book` und zur Darstellung unserer Entitäten erstellt.

1. Wir haben die Felder hinzugefügt, die die Eigenschaften unserer Entitäten enthalten.

1. Wir haben eine Abfrage hinzugefügt, um diese Informationen aus der Datenbank abzurufen.

1. Wir haben eine Mutation hinzugefügt, um Daten in der Datenbank zu manipulieren.

1. Wir haben Eingabetypen hinzugefügt, um unsere Objektparameter in der Mutation zu ersetzen und den Regeln von GraphQL zu entsprechen.

1. Wir haben die Abfrage und die Mutation zu unserem Stammschema hinzugefügt, damit die GraphQL-Implementierung die Position des Root-Typs versteht.

Wie Sie sehen können, stützt sich der Prozess der Erstellung eines Schemas auf viele Konzepte aus der Datenmodellierung (insbesondere der Datenbankmodellierung) im Allgemeinen. Sie können sich das Schema so vorstellen, dass es der Form der Daten aus der Quelle entspricht. Es dient auch als Modell, das der Resolver implementieren wird. In den folgenden Abschnitten erfahren Sie, wie Sie mithilfe verschiedener AWS unterstützter Tools und Dienste ein Schema erstellen.

**Anmerkung**  
Die Beispiele in den folgenden Abschnitten sind nicht für die Ausführung in einer echten Anwendung vorgesehen. Sie dienen nur dazu, die Befehle zu veranschaulichen, damit Sie Ihre eigenen Anwendungen erstellen können.

## Erstellen von Schemata
<a name="creating-schema"></a>

Ihr Schema wird sich in einer Datei mit dem Namen befinden`schema.graphql`. AWS AppSync ermöglicht es Benutzern, mit verschiedenen Methoden neue Schemas für ihr GraphQL APIs zu erstellen. In diesem Beispiel erstellen wir eine leere API zusammen mit einem leeren Schema.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **Dashboard** **Create API (API erstellen)** aus.

   1. Wählen Sie unter **API-Optionen** **GraphQL APIs**, **Von Grund auf neu entwerfen** und dann **Weiter** aus.

      1. Ändern Sie für den **API-Namen** den vorausgefüllten Namen in den Namen, den Ihre Anwendung benötigt.

      1. Für **Kontaktinformationen** können Sie eine Kontaktperson angeben, um einen Manager für die API zu identifizieren. Dies ist ein optionales Feld.

      1. Unter **Private API-Konfiguration** können Sie private API-Funktionen aktivieren. Auf eine private API kann nur von einem konfigurierten VPC-Endpunkt (VPCE) aus zugegriffen werden. [Weitere Informationen finden Sie unter Privat. APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html)

         Wir empfehlen, diese Funktion für dieses Beispiel nicht zu aktivieren. Wählen Sie „**Weiter**“, nachdem Sie Ihre Eingaben überprüft haben.

   1. Unter **GraphQL-Typ erstellen** können Sie wählen, ob Sie eine DynamoDB-Tabelle erstellen möchten, die Sie als Datenquelle verwenden möchten, oder dies überspringen und später tun möchten.

      Wählen Sie für dieses Beispiel **Create GraphQL resources later** aus. Wir werden eine Ressource in einem separaten Abschnitt erstellen.

   1. Überprüfe deine Eingaben und wähle dann **Create API**.

1. Sie befinden sich im Dashboard Ihrer spezifischen API. Sie können es daran erkennen, dass der Name der API oben im Dashboard angezeigt wird. Wenn dies nicht der Fall ist, können Sie **APIs**in der **Seitenleiste** auswählen und dann Ihre API im **APIs Dashboard** auswählen.

   1. **Wählen Sie in der **Seitenleiste** unter dem Namen Ihrer API Schema aus.**

1. Im **Schema-Editor** können Sie Ihre `schema.graphql` Datei konfigurieren. Sie kann leer sein oder mit Typen gefüllt sein, die aus einem Modell generiert wurden. Auf der rechten Seite befindet sich der Abschnitt **Resolver, in dem Sie Resolver** an Ihre Schemafelder anhängen können. In diesem Abschnitt werden wir uns nicht mit Resolvern befassen.

------
#### [ CLI ]

**Anmerkung**  
Stellen Sie bei der Verwendung der CLI sicher, dass Sie über die richtigen Berechtigungen für den Zugriff und die Erstellung von Ressourcen im Service verfügen. Möglicherweise möchten Sie Richtlinien mit den [geringsten Rechten für Benutzer ohne Administratorrechte](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) festlegen, die auf den Service zugreifen müssen. Weitere Informationen zu AWS AppSync Richtlinien finden Sie unter [Identitäts- und](https://docs.aws.amazon.com//appsync/latest/devguide/security-iam.html) Zugriffsverwaltung für. AWS AppSync  
Darüber hinaus empfehlen wir, zuerst die Konsolenversion zu lesen, falls Sie dies noch nicht getan haben.

1. Falls Sie dies noch nicht getan haben, [installieren Sie](https://docs.aws.amazon.com//cli/latest/userguide/cli-chap-getting-started.html) die AWS CLI und fügen Sie dann Ihre [Konfiguration](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-quickstart.html) hinzu.

1. Erstellen Sie ein GraphQL-API-Objekt, indem Sie den [https://docs.aws.amazon.com/cli/latest/reference/appsync/create-graphql-api.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-graphql-api.html)Befehl ausführen.

   Sie müssen zwei Parameter für diesen speziellen Befehl eingeben:

   1. Die `name` Ihrer API.

   1. Die oder die Art der Anmeldeinformationen`authentication-type`, die für den Zugriff auf die API verwendet werden (IAM, OIDC usw.).
**Anmerkung**  
Andere Parameter wie `Region` müssen konfiguriert werden, verwenden aber normalerweise standardmäßig Ihre CLI-Konfigurationswerte.

   Ein Beispielbefehl könnte wie folgt aussehen:

   ```
   aws appsync create-graphql-api --name testAPI123 --authentication-type API_KEY
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "graphqlApi": {
           "xrayEnabled": false,
           "name": "testAPI123",
           "authenticationType": "API_KEY",
           "tags": {},
           "apiId": "abcdefghijklmnopqrstuvwxyz",
           "uris": {
               "GRAPHQL": "https://zyxwvutsrqponmlkjihgfedcba.appsync-api.us-west-2.amazonaws.com/graphql",
               "REALTIME": "wss://zyxwvutsrqponmlkjihgfedcba.appsync-realtime-api.us-west-2.amazonaws.com/graphql"
           },
           "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz"
       }
   }
   ```

1. 
**Anmerkung**  
Dies ist ein optionaler Befehl, der ein vorhandenes Schema verwendet und es mithilfe eines Base-64-Blobs in den AWS AppSync Dienst hochlädt. Wir werden diesen Befehl nicht für dieses Beispiel verwenden.

   Führen Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/appsync/start-schema-creation.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/start-schema-creation.html) aus.

   Für diesen speziellen Befehl müssen Sie zwei Parameter eingeben:

   1. Ihr `api-id` aus dem vorherigen Schritt.

   1. Das Schema `definition` ist ein Base-64-codierter binärer Blob.

   Ein Beispielbefehl könnte wie folgt aussehen:

   ```
    aws appsync start-schema-creation --api-id abcdefghijklmnopqrstuvwxyz --definition "aa1111aa-123b-2bb2-c321-12hgg76cc33v"
   ```

   Es wird eine Ausgabe zurückgegeben:

   ```
   {
       "status": "PROCESSING"
   }
   ```

   Dieser Befehl gibt nach der Verarbeitung nicht die endgültige Ausgabe zurück. Sie müssen einen separaten Befehl verwenden [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/get-schema-creation-status.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/get-schema-creation-status.html), um das Ergebnis zu sehen. Beachten Sie, dass diese beiden Befehle asynchron sind, sodass Sie den Ausgabestatus überprüfen können, auch wenn das Schema noch erstellt wird.

------
#### [ CDK ]

**Tipp**  
[Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit AWS AppSync der CDK-Referenz zu lesen.](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html)  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.

1. Der Ausgangspunkt für das CDK ist etwas anders. Idealerweise sollte Ihre `schema.graphql` Datei bereits erstellt sein. Sie müssen nur eine neue Datei mit der `.graphql` Dateierweiterung erstellen. Dies kann eine leere Datei sein.

1. Im Allgemeinen müssen Sie möglicherweise die Import-Direktive zu dem Dienst hinzufügen, den Sie verwenden. Zum Beispiel kann es den folgenden Formen folgen:

   ```
   import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
   import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'
   ```

   Um eine GraphQL-API hinzuzufügen, muss Ihre Stack-Datei den AWS AppSync Dienst importieren:

   ```
   import * as appsync from 'aws-cdk-lib/aws-appsync';
   ```
**Anmerkung**  
Das bedeutet, dass wir den gesamten Service unter dem `appsync` Schlüsselwort importieren. Um dies in Ihrer App zu verwenden, verwenden Ihre AWS AppSync Konstrukte das Format`appsync.construct_name`. Wenn wir zum Beispiel eine GraphQL-API erstellen wollten, würden wir sagen`new appsync.GraphqlApi(args_go_here)`. Der folgende Schritt zeigt dies.

1. Die grundlegendste GraphQL-API wird eine `name` für die API und den `schema` Pfad enthalten.

   ```
   const add_api = new appsync.GraphqlApi(this, 'API_ID', {
     name: 'name_of_API_in_console',
     schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema_name.graphql')),
   });
   ```
**Anmerkung**  
Sehen wir uns an, was dieser Ausschnitt bewirkt. Im Rahmen von `api` erstellen wir eine neue GraphQL-API, indem wir aufrufen`appsync.GraphqlApi(scope: Construct, id: string, props: GraphqlApiProps)`. Der Gültigkeitsbereich ist`this`, was sich auf das aktuelle Objekt bezieht. Die ID lautet*API\$1ID*, was der Ressourcenname Ihrer GraphQL-API sein wird, CloudFormation wenn sie erstellt wird. Das `GraphqlApiProps` enthält die `name` Ihrer GraphQL-API und die`schema`. Das `schema` generiert ein Schema (`SchemaFile.fromAsset`), indem es den absoluten Pfad (`__dirname`) nach der `.graphql` Datei (*schema\$1name.graphql*) durchsucht. In einem realen Szenario befindet sich Ihre Schemadatei wahrscheinlich in der CDK-App.  
Um die an Ihrer GraphQL-API vorgenommenen Änderungen verwenden zu können, müssen Sie die App erneut bereitstellen.

------

## Hinzufügen von Typen zu Schemas
<a name="adding-schema-types"></a>

Nachdem Sie Ihr Schema hinzugefügt haben, können Sie damit beginnen, sowohl Ihre Eingabe- als auch Ihre Ausgabetypen hinzuzufügen. Beachten Sie, dass die hier aufgeführten Typen nicht in echtem Code verwendet werden sollten. Sie sind lediglich Beispiele, die Ihnen helfen sollen, den Prozess zu verstehen.

Zuerst erstellen wir einen Objekttyp. In echtem Code müssen Sie nicht mit diesen Typen beginnen. Sie können jederzeit jeden beliebigen Typ erstellen, solange Sie die Regeln und die Syntax von GraphQL befolgen.

**Anmerkung**  
In den nächsten Abschnitten wird der **Schema-Editor** verwendet, lassen Sie ihn also offen.

------
#### [ Console ]
+ Sie können einen Objekttyp erstellen, indem Sie das `type` Schlüsselwort zusammen mit dem Namen des Typs verwenden:

  ```
  type Type_Name_Goes_Here {}
  ```

  Innerhalb des Gültigkeitsbereichs des Typs können Sie Felder hinzufügen, die die Eigenschaften des Objekts repräsentieren:

  ```
  type Type_Name_Goes_Here {
    # Add fields here
  }
  ```

  Hier ein Beispiel:

  ```
  type Obj_Type_1 {
    id: ID!
    title: String
    date: AWSDateTime
  }
  ```
**Anmerkung**  
In diesem Schritt haben wir einen generischen Objekttyp hinzugefügt, bei dem ein erforderliches `id` Feld gespeichert als`ID`, ein `title` Feld gespeichert als und ein `date` Feld`String`, das als gespeichert ist`AWSDateTime`. Eine Liste der Typen und Felder und ihrer Funktionsweise finden Sie unter [Schemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html). Eine Liste der Skalare und ihrer Funktionsweise finden Sie in der [Typenreferenz](https://docs.aws.amazon.com/appsync/latest/devguide/type-reference.html).

------
#### [ CLI ]

**Anmerkung**  
Wir empfehlen, zuerst die Konsolenversion zu lesen, falls Sie dies noch nicht getan haben.
+ Sie können einen Objekttyp erstellen, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html)Befehl ausführen.

  Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Der `definition` oder der Inhalt Ihres Typs. Im Konsolenbeispiel war das:

     ```
     type Obj_Type_1 {
       id: ID!
       title: String
       date: AWSDateTime
     }
     ```

  1. Die `format` deiner Eingabe. In diesem Beispiel verwenden wir`SDL`.

  Ein Beispielbefehl könnte so aussehen:

  ```
  aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "type Obj_Type_1{id: ID! title: String date: AWSDateTime}" --format SDL
  ```

  Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

  ```
  {
      "type": {
          "definition": "type Obj_Type_1{id: ID! title: String date: AWSDateTime}",
          "name": "Obj_Type_1",
          "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Obj_Type_1",
          "format": "SDL"
      }
  }
  ```
**Anmerkung**  
In diesem Schritt haben wir einen generischen Objekttyp mit einem erforderlichen `id` Feld hinzugefügt, das als gespeichert ist`ID`, einem `title` Feld, das als gespeichert ist`String`, und einem `date` Feld, das als gespeichert ist`AWSDateTime`. Eine Liste der Typen und Felder und ihrer Funktionsweise finden Sie unter [Schemas](https://docs.aws.amazon.com//appsync/latest/devguide/schema-components.html). Eine Liste der Skalare und ihrer Funktionsweise finden Sie unter [Typenreferenz](https://docs.aws.amazon.com/appsync/latest/devguide/type-reference.html).  
Außerdem haben Sie vielleicht bemerkt, dass die direkte Eingabe der Definition für kleinere Typen funktioniert, für das Hinzufügen größerer oder mehrerer Typen jedoch nicht möglich ist. Sie können sich dafür entscheiden, alles in einer `.graphql` Datei hinzuzufügen und [es dann als Eingabe zu übergeben](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html).

------
#### [ CDK ]

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir Ihnen, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.

Um einen Typ hinzuzufügen, müssen Sie ihn zu Ihrer `.graphql` Datei hinzufügen. Das Konsolenbeispiel lautete zum Beispiel:

```
type Obj_Type_1 {
  id: ID!
  title: String
  date: AWSDateTime
}
```

Sie können Ihre Typen wie jede andere Datei direkt zum Schema hinzufügen.

**Anmerkung**  
Um die an Ihrer GraphQL-API vorgenommenen Änderungen verwenden zu können, müssen Sie die App erneut bereitstellen.

------

Der [Objekttyp](https://graphql.org/learn/schema/#object-types-and-fields) hat Felder, bei denen es sich um [skalare Typen](https://graphql.org/learn/schema/#scalar-types) wie Zeichenketten und Ganzzahlen handelt. AWS AppSync ermöglicht es Ihnen auch, erweiterte Skalartypen wie `AWSDateTime` zusätzlich zu den Basis-GraphQL-Skalaren zu verwenden. Außerdem ist jedes Feld, das mit einem Ausrufezeichen endet, erforderlich. 

Insbesondere der `ID` skalare Typ ist ein eindeutiger Bezeichner, der entweder oder sein kann. `String` `Int` Sie können diese in Ihrem Resolver-Code für die automatische Zuweisung steuern.

Es gibt Ähnlichkeiten zwischen speziellen Objekttypen wie `Query` und „normalen“ Objekttypen wie dem obigen Beispiel, da sie beide das `type` Schlüsselwort verwenden und als Objekte betrachtet werden. Bei den speziellen Objekttypen (`Query``Mutation`, und`Subscription`) unterscheidet sich ihr Verhalten jedoch erheblich, da sie als Einstiegspunkte für Ihre API bereitgestellt werden. Außerdem geht es bei ihnen eher um die Gestaltung von Vorgängen als um Daten. Weitere Informationen finden Sie unter [Die Abfrage- und Mutationstypen](https://graphql.org/learn/schema/#the-query-and-mutation-types).

Was spezielle Objekttypen angeht, könnte der nächste Schritt darin bestehen, einen oder mehrere von ihnen hinzuzufügen, um Operationen an den geformten Daten durchzuführen. In einem realen Szenario muss jedes GraphQL-Schema mindestens einen Root-Abfragetyp zum Anfordern von Daten haben. Sie können sich die Abfrage als einen der Einstiegspunkte (oder Endpunkte) für Ihren GraphQL-Server vorstellen. Fügen wir als Beispiel eine Abfrage hinzu.

------
#### [ Console ]
+ Um eine Abfrage zu erstellen, können Sie sie einfach wie jeden anderen Typ zur Schemadatei hinzufügen. Eine Abfrage würde einen `Query` Typ und einen Eintrag im Stammverzeichnis wie folgt erfordern:

  ```
  schema {
    query: Name_of_Query
  }
  
  type Name_of_Query {
    # Add field operation here
  }
  ```

  Beachten Sie, dass *Name\$1of\$1Query* in einer Produktionsumgebung `Query` in den meisten Fällen einfach aufgerufen wird. Wir empfehlen, diesen Wert beizubehalten. Innerhalb des Abfragetyps können Sie Felder hinzufügen. Jedes Feld führt eine Operation in der Anfrage aus. Infolgedessen werden die meisten, wenn nicht alle dieser Felder an einen Resolver angehängt. In diesem Abschnitt befassen wir uns jedoch nicht damit. In Bezug auf das Format der Feldoperation könnte es so aussehen:

  ```
  Name_of_Query(params): Return_Type # version with params
  Name_of_Query: Return_Type # version without params
  ```

  Hier ein Beispiel:

  ```
  schema {
    query: Query
  }
  
  type Query {
    getObj: [Obj_Type_1]
  }
  
  type Obj_Type_1 {
    id: ID!
    title: String
    date: AWSDateTime
  }
  ```
**Anmerkung**  
In diesem Schritt haben wir einen `Query` Typ hinzugefügt und ihn in unserem `schema` Stammverzeichnis definiert. Unser `Query` Typ hat ein `getObj` Feld definiert, das eine Liste von `Obj_Type_1` Objekten zurückgibt. Beachten Sie, `Obj_Type_1` dass dies das Objekt des vorherigen Schritts ist. Im Produktionscode arbeiten Ihre Außendienstmitarbeiter normalerweise mit Daten, die von Objekten wie geformt sind`Obj_Type_1`. Darüber hinaus verfügen Felder wie `getObj` normalerweise über einen Resolver, der die Geschäftslogik ausführt. Das wird in einem anderen Abschnitt behandelt.  
Als zusätzlicher Hinweis wird bei Exporten AWS AppSync automatisch ein Schema-Root hinzugefügt, sodass Sie es technisch gesehen nicht direkt zum Schema hinzufügen müssen. Unser Service verarbeitet automatisch doppelte Schemas. Wir fügen es hier als bewährte Methode hinzu.

------
#### [ CLI ]

**Anmerkung**  
Wir empfehlen, zuerst die Konsolenversion zu lesen, falls Sie dies noch nicht getan haben.

1. Erstellen Sie ein `schema` Stammverzeichnis mit einer `query` Definition, indem [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html)Sie den Befehl ausführen.

   Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

   1. Die `api-id` Ihrer API.

   1. Der `definition` oder der Inhalt Ihres Typs. Im Konsolenbeispiel war das:

      ```
      schema {
        query: Query
      }
      ```

   1. Die `format` deiner Eingabe. In diesem Beispiel verwenden wir`SDL`.

   Ein Beispielbefehl könnte so aussehen:

   ```
   aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "schema {query: Query}" --format SDL
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "type": {
           "definition": "schema {query: Query}",
           "name": "schema",
           "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/schema",
           "format": "SDL"
       }
   }
   ```
**Anmerkung**  
Beachten Sie, dass Sie Ihren Schemastamm (oder einen beliebigen Typ im Schema) aktualisieren können, indem Sie den `create-type` Befehl ausführen, wenn Sie etwas nicht korrekt in den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html)Befehl eingegeben haben. In diesem Beispiel ändern wir vorübergehend den Schemastamm, sodass er eine `subscription` Definition enthält.  
Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:  
Die `api-id` Ihrer API.
Die `type-name` deines Typs. Im Konsolenbeispiel war das`schema`.
Der `definition` oder der Inhalt Ihres Typs. Im Konsolenbeispiel war das:  

      ```
      schema {
        query: Query
      }
      ```
Das Schema nach dem Hinzufügen von `subscription` sieht so aus:  

      ```
      schema {
        query: Query
        subscription: Subscription
      }
      ```
Die `format` deiner Eingabe. In diesem Beispiel verwenden wir`SDL`.
Ein Beispielbefehl könnte so aussehen:  

   ```
   aws appsync update-type --api-id abcdefghijklmnopqrstuvwxyz --type-name schema --definition "schema {query: Query subscription: Subscription}" --format SDL
   ```
Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:  

   ```
   {
       "type": {
           "definition": "schema {query: Query subscription: Subscription}",
           "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/schema",
           "format": "SDL"
       }
   }
   ```
Das Hinzufügen vorformatierter Dateien funktioniert in diesem Beispiel weiterhin.

1. Erstellen Sie einen `Query` Typ, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html)Befehl ausführen.

   Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

   1. Die `api-id` Ihrer API.

   1. Der `definition` oder der Inhalt Ihres Typs. Im Konsolenbeispiel war das:

      ```
      type Query {
        getObj: [Obj_Type_1]
      }
      ```

   1. Die `format` deiner Eingabe. In diesem Beispiel verwenden wir`SDL`.

   Ein Beispielbefehl könnte so aussehen:

   ```
   aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "type Query {getObj: [Obj_Type_1]}" --format SDL
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "type": {
           "definition": "Query {getObj: [Obj_Type_1]}",
           "name": "Query",
           "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Query",
           "format": "SDL"
       }
   }
   ```
**Anmerkung**  
In diesem Schritt haben wir einen `Query` Typ hinzugefügt und ihn in Ihrem `schema` Stammverzeichnis definiert. Unser `Query` Typ hat ein `getObj` Feld definiert, das eine Liste von `Obj_Type_1` Objekten zurückgab.  
Im `schema` Stammcode gibt der `query:` Teil an`query: Query`, dass eine Abfrage in Ihrem Schema definiert wurde, während der `Query` Teil den tatsächlichen Namen des speziellen Objekts angibt. 

------
#### [ CDK ]

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.

Sie müssen Ihre Abfrage und den Schemastamm zur `.graphql` Datei hinzufügen. Unser Beispiel sah wie das folgende Beispiel aus, aber Sie sollten es durch Ihren tatsächlichen Schemacode ersetzen:

```
schema {
  query: Query
}

type Query {
  getObj: [Obj_Type_1]
}

type Obj_Type_1 {
  id: ID!
  title: String
  date: AWSDateTime
}
```

Sie können Ihre Typen wie jede andere Datei direkt zum Schema hinzufügen.

**Anmerkung**  
Die Aktualisierung des Schemastammes ist optional. Wir haben es als bewährte Methode zu diesem Beispiel hinzugefügt.  
Um die an Ihrer GraphQL-API vorgenommenen Änderungen verwenden zu können, müssen Sie die App erneut bereitstellen.

------

Sie haben jetzt ein Beispiel für die Erstellung von Objekten und speziellen Objekten (Abfragen) gesehen. Sie haben auch gesehen, wie diese miteinander verbunden werden können, um Daten und Operationen zu beschreiben. Sie können Schemas verwenden, die nur die Datenbeschreibung und eine oder mehrere Abfragen enthalten. Wir möchten jedoch eine weitere Operation hinzufügen, um der Datenquelle Daten hinzuzufügen. Wir werden einen weiteren speziellen Objekttyp hinzufügen`Mutation`, der Daten modifiziert.

------
#### [ Console ]
+ Eine Mutation wird aufgerufen`Mutation`. Die darin `Mutation` enthaltenen Feldoperationen beschreiben zum Beispiel `Query` eine Operation und werden an einen Resolver angehängt. Beachten Sie auch, dass wir es im `schema` Stammverzeichnis definieren müssen, da es sich um einen speziellen Objekttyp handelt. Hier ist ein Beispiel für eine Mutation:

  ```
  schema {
    mutation: Name_of_Mutation
  }
  
  type Name_of_Mutation {
    # Add field operation here
  }
  ```

  Eine typische Mutation wird wie eine Abfrage im Stammverzeichnis aufgeführt. Die Mutation wird mit dem `type` Schlüsselwort zusammen mit dem Namen definiert. *Name\$1of\$1Mutation*wird normalerweise aufgerufen`Mutation`, daher empfehlen wir, es so zu belassen. Jedes Feld führt auch eine Operation aus. In Bezug auf das Format der Feldoperation könnte es so aussehen:

  ```
  Name_of_Mutation(params): Return_Type # version with params
  Name_of_Mutation: Return_Type # version without params
  ```

  Hier ein Beispiel:

  ```
  schema {
    query: Query
    mutation: Mutation
  }
  
  type Obj_Type_1 {
    id: ID!
    title: String
    date: AWSDateTime
  }
  
  type Query {
    getObj: [Obj_Type_1]
  }
  
  type Mutation {
    addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
  }
  ```
**Anmerkung**  
In diesem Schritt haben wir einen `Mutation` Typ mit einem `addObj` Feld hinzugefügt. Lassen Sie uns zusammenfassen, was dieses Feld tut:  

  ```
  addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
  ```
`addObj`verwendet das `Obj_Type_1` Objekt, um eine Operation auszuführen. Das liegt an den Feldern, aber die Syntax beweist dies im `: Obj_Type_1` Rückgabetyp. `addObj`Im Inneren akzeptiert es die `date` Felder `id``title`, und aus dem `Obj_Type_1` Objekt als Parameter. Wie Sie vielleicht sehen, sieht es einer Methodendeklaration sehr ähnlich. Wir haben das Verhalten unserer Methode jedoch noch nicht beschrieben. Wie bereits erwähnt, dient das Schema nur dazu, zu definieren, wie die Daten und Operationen aussehen werden, und nicht, wie sie funktionieren. Die Implementierung der eigentlichen Geschäftslogik erfolgt später, wenn wir unsere ersten Resolver erstellen.  
Sobald Sie mit Ihrem Schema fertig sind, besteht die Möglichkeit, es als `schema.graphql` Datei zu exportieren. Im **Schema-Editor** können Sie **Schema exportieren** wählen, um die Datei in einem unterstützten Format herunterzuladen.  
Ein zusätzlicher Hinweis: Fügt bei Exporten AWS AppSync automatisch ein Schema-Root hinzu, sodass Sie es technisch gesehen nicht direkt zum Schema hinzufügen müssen. Unser Service verarbeitet automatisch doppelte Schemas. Wir fügen es hier als bewährte Methode hinzu.

------
#### [ CLI ]

**Anmerkung**  
Wir empfehlen, zuerst die Konsolenversion zu lesen, falls Sie dies noch nicht getan haben.

1. Aktualisieren Sie Ihr Stammschema, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-type.html)Befehl ausführen.

   Sie müssen einige Parameter für diesen speziellen Befehl eingeben:

   1. Die `api-id` Ihrer API.

   1. Die `type-name` deines Typs. Im Konsolenbeispiel war das`schema`.

   1. Der `definition` oder der Inhalt Ihres Typs. Im Konsolenbeispiel war das:

      ```
      schema {
        query: Query
        mutation: Mutation
      }
      ```

   1. Die `format` deiner Eingabe. In diesem Beispiel verwenden wir`SDL`.

   Ein Beispielbefehl könnte so aussehen:

   ```
   aws appsync update-type --api-id abcdefghijklmnopqrstuvwxyz --type-name schema --definition "schema {query: Query mutation: Mutation}" --format SDL
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "type": {
           "definition": "schema {query: Query mutation: Mutation}",
           "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/schema",
           "format": "SDL"
       }
   }
   ```

1. Erstellen Sie einen `Mutation` Typ, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-type.html)Befehl ausführen.

   Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

   1. Die `api-id` Ihrer API.

   1. Der `definition` oder der Inhalt Ihres Typs. Im Konsolenbeispiel war das

      ```
      type Mutation {
        addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
      }
      ```

   1. Die `format` deiner Eingabe. In diesem Beispiel verwenden wir`SDL`.

   Ein Beispielbefehl könnte so aussehen:

   ```
   aws appsync create-type --api-id abcdefghijklmnopqrstuvwxyz --definition "type Mutation {addObj(id: ID! title: String date: AWSDateTime): Obj_Type_1}" --format SDL
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "type": {
           "definition": "type Mutation {addObj(id: ID! title: String date: AWSDateTime): Obj_Type_1}",
           "name": "Mutation",
           "arn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation",
           "format": "SDL"
       }
   }
   ```

------
#### [ CDK ]

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.

Sie müssen Ihre Abfrage und den Schemastamm zur `.graphql` Datei hinzufügen. Unser Beispiel sah wie das folgende Beispiel aus, aber Sie sollten es durch Ihren tatsächlichen Schemacode ersetzen:

```
schema {
  query: Query
  mutation: Mutation
}

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

type Query {
  getObj: [Obj_Type_1]
}

type Mutation {
  addObj(id: ID!, title: String, date: AWSDateTime): Obj_Type_1
}
```

**Anmerkung**  
Das Aktualisieren des Schema-Stammverzeichnisses ist optional. Wir haben es als bewährte Methode zu diesem Beispiel hinzugefügt.  
Um die an Ihrer GraphQL-API vorgenommenen Änderungen verwenden zu können, müssen Sie die App erneut bereitstellen.

------

## Optionale Überlegungen — Verwendung von Enums als Status
<a name="optional-consideration-enums"></a>

Zu diesem Zeitpunkt wissen Sie, wie man ein grundlegendes Schema erstellt. Es gibt jedoch viele Dinge, die Sie hinzufügen könnten, um die Funktionalität des Schemas zu erhöhen. Eine häufig vorkommende Sache in Anwendungen ist die Verwendung von Enums als Status. Sie können eine Aufzählung verwenden, um zu erzwingen, dass beim Aufruf ein bestimmter Wert aus einer Menge von Werten ausgewählt wird. Das ist gut für Dinge, von denen Sie wissen, dass sie sich über lange Zeiträume nicht drastisch ändern werden. Hypothetisch gesehen könnten wir eine Aufzählung hinzufügen, die den Statuscode oder die Zeichenfolge in der Antwort zurückgibt. 

Nehmen wir als Beispiel an, wir erstellen eine Social-Media-App, die die Beitragsdaten eines Benutzers im Backend speichert. Unser Schema enthält einen `Post` Typ, der die Daten eines einzelnen Beitrags darstellt:

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

Unser `Post` wird einen eindeutigen `id` Beitrag und eine `title` `date` Aufzählung mit dem Namen enthalten, `PostStatus` die den Status des Beitrags angibt, während er von der App verarbeitet wird. Für unseren Betrieb werden wir eine Abfrage haben, die alle Beitragsdaten zurückgibt:

```
type Query {
  getPosts: [Post]
}
```

Wir werden auch eine Mutation haben, die Beiträge zur Datenquelle hinzufügt:

```
type Mutation {
  addPost(id: ID!, title: String, date: AWSDateTime, poststatus: PostStatus): Post
}
```

Wenn wir uns unser Schema ansehen, könnte die `PostStatus` Aufzählung mehrere Status haben. Möglicherweise möchten wir, dass die drei grundlegenden Status `success` (Post erfolgreich verarbeitet), `pending` (Post wird verarbeitet) und `error` (Beitrag kann nicht verarbeitet werden) heißen. Um die Aufzählung hinzuzufügen, könnten wir Folgendes tun:

```
enum PostStatus {
  success
  pending
  error
}
```

Das vollständige Schema könnte so aussehen:

```
schema {
  query: Query
  mutation: Mutation
}

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

type Mutation {
  addPost(id: ID!, title: String, date: AWSDateTime, poststatus: PostStatus): Post
}

type Query {
  getPosts: [Post]
}

enum PostStatus {  
  success
  pending
  error
}
```

Wenn ein Benutzer der Anwendung eine `Post` hinzufügt, wird die `addPost` Operation aufgerufen, um diese Daten zu verarbeiten. Während der damit verbundene Resolver die Daten `addPost` verarbeitet, aktualisiert er sie kontinuierlich `poststatus` mit dem Status des Vorgangs. Wenn sie abgefragt `Post` werden, enthält sie den endgültigen Status der Daten. Denken Sie daran, dass wir nur beschreiben, wie die Daten im Schema funktionieren sollen. Wir gehen von der Implementierung unserer Resolver (s) aus, die die eigentliche Geschäftslogik für die Verarbeitung der Daten zur Erfüllung der Anfrage implementieren.

## Optionale Überlegungen — Abonnements
<a name="optional-consideration-subscriptions"></a>

Abonnements in AWS AppSync werden als Reaktion auf eine Mutation aufgerufen. Diese werden mit einem `Subscription`-Typ und einer `@aws_subscribe()`-Anweisung im Schema konfiguriert, um anzugeben, welche Mutationen ein oder mehrere Abonnements aufrufen. Weitere Informationen zur Konfiguration von Abonnements finden Sie unter [Echtzeitdaten](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html).

## Optionale Überlegungen — Beziehungen und Seitennummerierung
<a name="optional-consideration-relations-and-pagination"></a>

Angenommen, Sie haben eine Million in einer DynamoDB-Tabelle `Posts` gespeichert und möchten einige dieser Daten zurückgeben. Die oben angegebene Beispielabfrage gibt jedoch nur alle Beiträge zurück. Sie möchten nicht jedes Mal, wenn Sie eine Anfrage stellen, alle abrufen. Stattdessen würden Sie sie [paginieren](https://graphql.org/learn/pagination/) wollen. Nehmen Sie dazu die folgenden Änderungen an Ihrem Schema vor:
+ Fügen Sie im `getPosts` Feld zwei Eingabeargumente hinzu: `nextToken` (Iterator) und `limit` (Iterationslimit).
+ Fügen Sie einen neuen `PostIterator` Typ hinzu, der `Posts` Felder (ruft die `Post` Objektliste ab) und `nextToken` (Iterator) enthält.
+ Ändern Sie es `getPosts` so, dass es zurückgegeben wird `PostIterator` und keine Liste von `Post` Objekten.

```
schema {
  query: Query
  mutation: Mutation
}

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

type Mutation {
  addPost(id: ID!, title: String, date: AWSDateTime, poststatus: PostStatus): Post
}

type Query {
  getPosts(limit: Int, nextToken: String): PostIterator
}

enum PostStatus {
  success
  pending
  error
}

type PostIterator {
  posts: [Post]
  nextToken: String
}
```

Der `PostIterator` Typ ermöglicht es Ihnen, einen Teil der `Post` Objektliste zurückzugeben und einen, `nextToken` um den nächsten Teil abzurufen. Darin befindet `PostIterator` sich eine Liste von `Post` Elementen (`[Post]`), die mit einem Paginierungstoken (`nextToken`) zurückgegeben wird. AWS AppSyncIn würde dies über einen Resolver mit Amazon DynamoDB verbunden und automatisch als verschlüsseltes Token generiert. Dadurch wird der Wert des Arguments `limit` in den Parameter `maxResults` und des Arguments `nextToken` in den Parameter `exclusiveStartKey` konvertiert. Beispiele und die integrierten Vorlagenbeispiele in der AWS AppSync Konsole finden Sie unter [Resolver-Referenz](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html) (). JavaScript

# Eine Datenquelle anhängen in AWS AppSync
<a name="attaching-a-data-source"></a>

Datenquellen sind Ressourcen in Ihrem AWS Konto, mit denen GraphQL interagieren APIs kann. AWS AppSync unterstützt eine Vielzahl von Datenquellen wie AWS Lambda Amazon DynamoDB, relationale Datenbanken (Amazon Aurora Serverless), Amazon OpenSearch Service und HTTP-Endpunkte. Eine AWS AppSync API kann so konfiguriert werden, dass sie mit mehreren Datenquellen interagiert, sodass Sie Daten an einem einzigen Ort aggregieren können. AWS AppSync kann vorhandene AWS Ressourcen aus Ihrem Konto verwenden oder DynamoDB-Tabellen in Ihrem Namen anhand einer Schemadefinition bereitstellen.

Der folgende Abschnitt zeigt Ihnen, wie Sie eine Datenquelle an Ihre GraphQL-API anhängen.

## Arten von Datenquellen
<a name="data-source-types"></a>

Nachdem Sie in der AWS AppSync Konsole ein Schema erstellt haben, können Sie eine Datenquelle daran anhängen. Wenn Sie zum ersten Mal eine API erstellen, besteht die Möglichkeit, während der Erstellung des vordefinierten Schemas eine Amazon DynamoDB-Tabelle bereitzustellen. Wir werden diese Option in diesem Abschnitt jedoch nicht behandeln. Ein Beispiel dafür finden Sie im Abschnitt [Ein Schema starten](https://docs.aws.amazon.com//appsync/latest/devguide/schema-launch-start.html).

Stattdessen werden wir uns alle AWS AppSync unterstützten Datenquellen ansehen. Es gibt viele Faktoren, die bei der Auswahl der richtigen Lösung für Ihre Anwendung eine Rolle spielen. Die folgenden Abschnitte bieten zusätzlichen Kontext für jede Datenquelle. Allgemeine Informationen zu Datenquellen finden Sie unter [Datenquellen](https://docs.aws.amazon.com/appsync/latest/devguide/data-source-components.html).

### Amazon DynamoDB
<a name="data-source-type-ddb"></a>

Amazon DynamoDB ist eine der wichtigsten AWS Speicherlösungen für skalierbare Anwendungen. Die Kernkomponente von DynamoDB ist die **Tabelle**, bei der es sich einfach um eine Sammlung von Daten handelt. In der Regel erstellen Sie Tabellen, die auf Entitäten wie `Book` oder basieren. `Author` Informationen zu Tabelleneinträgen werden als **Elemente** gespeichert. Dabei handelt es sich um Gruppen von Feldern, die für jeden Eintrag einzigartig sind. Ein vollständiges Element steht für ein Element row/record in der Datenbank. Ein Element für einen `Book` Eintrag kann beispielsweise `title` und `author` zusammen mit ihren Werten enthalten. Die einzelnen Felder wie das `title` und `author` werden als **Attribute** bezeichnet, was den Spaltenwerten in relationalen Datenbanken ähnelt. 

Wie Sie sich vorstellen können, werden Tabellen zum Speichern von Daten aus Ihrer Anwendung verwendet. AWS AppSync ermöglicht es Ihnen, Ihre DynamoDB-Tabellen mit Ihrer GraphQL-API zu verbinden, um Daten zu manipulieren. Nehmen Sie diesen [Anwendungsfall](https://aws.amazon.com/blogs/mobile/new-real-time-multi-group-app-with-aws-amplify-graphql-build-a-twitter-community-clone/) aus dem *Frontend-Blog für Web* und Mobilgeräte. Mit dieser Anwendung können sich Benutzer für eine Social-Media-App anmelden. Benutzer können Gruppen beitreten und Beiträge hochladen, die an andere Benutzer gesendet werden, die die Gruppe abonniert haben. Ihre Anwendung speichert Benutzer-, Post- und Benutzergruppeninformationen in DynamoDB. Die GraphQL-API (verwaltet von AWS AppSync) ist mit der DynamoDB-Tabelle verbunden. Wenn ein Benutzer eine Änderung am System vornimmt, die sich im Frontend widerspiegelt, ruft die GraphQL-API diese Änderungen ab und überträgt sie in Echtzeit an andere Benutzer.

### AWS Lambda
<a name="data-source-type-lam"></a>

Lambda ist ein ereignisgesteuerter Dienst, der automatisch die erforderlichen Ressourcen aufbaut, um Code als Reaktion auf ein Ereignis auszuführen. Lambda verwendet **Funktionen**, bei denen es sich um Gruppenanweisungen handelt, die den Code, die Abhängigkeiten und die Konfigurationen für die Ausführung einer Ressource enthalten. Funktionen werden automatisch ausgeführt, wenn sie einen **Trigger** erkennen, eine Gruppe von Aktivitäten, die Ihre Funktion aufrufen. Ein Trigger kann so etwas wie eine Anwendung sein, die einen API-Aufruf durchführt, ein AWS Dienst in Ihrem Konto, der eine Ressource hochlädt usw. Wenn sie ausgelöst werden, verarbeiten Funktionen **Ereignisse**, bei denen es sich um JSON-Dokumente handelt, die die zu ändernden Daten enthalten.

Lambda eignet sich gut zum Ausführen von Code, ohne die Ressourcen für die Ausführung bereitstellen zu müssen. Nehmen Sie diesen [Anwendungsfall](https://aws.amazon.com/blogs/mobile/building-a-graphql-api-with-java-and-aws-lambda/) aus dem *Frontend-Blog für Web und Mobilgeräte*. Dieser Anwendungsfall ist dem im Abschnitt DynamoDB vorgestellten ein wenig ähnlich. In dieser Anwendung ist die GraphQL-API dafür verantwortlich, die Operationen für Dinge wie das Hinzufügen von Beiträgen (Mutationen) und das Abrufen dieser Daten (Abfragen) zu definieren. Um die Funktionalität ihrer Operationen zu implementieren (z. B.,`getPostsByAuthor ( author: String ! ) : [ Post ]`)`getPost ( id: String ! ) : Post`, verwenden sie Lambda-Funktionen, um eingehende Anfragen zu verarbeiten. *Option 2: AWS AppSync Mit Lambda-Resolver* verwenden sie den AWS AppSync Dienst, um ihr Schema zu verwalten und eine Lambda-Datenquelle mit einer der Operationen zu verknüpfen. Wenn der Vorgang aufgerufen wird, stellt Lambda eine Verbindung zum Amazon RDS-Proxy her, um die Geschäftslogik in der Datenbank auszuführen.

### Amazon RDS
<a name="data-source-type-RDS"></a>

Mit Amazon RDS können Sie schnell relationale Datenbanken erstellen und konfigurieren. In Amazon RDS erstellen Sie eine generische **Datenbank-Instance**, die als isolierte Datenbankumgebung in der Cloud dient. In diesem Fall verwenden Sie eine **DB-Engine**, bei der es sich um die eigentliche RDBMS-Software (PostgreSQL, MySQL usw.) handelt. Der Service entlastet einen Großteil der Backend-Arbeit, indem er Skalierbarkeit mithilfe AWS von Infrastruktur und Sicherheitsdiensten wie Patching und Verschlüsselung bietet und die Verwaltungskosten für Implementierungen senkt.

Nehmen Sie denselben [Anwendungsfall](https://aws.amazon.com/blogs/mobile/building-a-graphql-api-with-java-and-aws-lambda/) aus dem Abschnitt Lambda. Unter *Option 3: AWS AppSync mit Amazon RDS Resolver* wird eine weitere Option vorgestellt, die GraphQL-API direkt mit Amazon RDS AWS AppSync zu verknüpfen. Mithilfe einer [Daten-API](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html) verknüpfen sie die Datenbank mit der GraphQL-API. Ein Resolver ist an ein Feld angehängt (normalerweise eine Abfrage, Mutation oder ein Abonnement) und implementiert die SQL-Anweisungen, die für den Zugriff auf die Datenbank erforderlich sind. Wenn der Client eine Anfrage stellt, die das Feld aufruft, führt der Resolver die Anweisungen aus und gibt die Antwort zurück.

### Amazon EventBridge
<a name="data-source-type-eventbridge"></a>

In EventBridge erstellen Sie **Event-Busse**. Dabei handelt es sich um Pipelines, die Ereignisse von Diensten oder Anwendungen empfangen, die Sie anhängen (die **Ereignisquelle**), und diese auf der Grundlage einer Reihe von Regeln verarbeiten. Ein **Ereignis** ist eine Zustandsänderung in einer Ausführungsumgebung, während eine **Regel** eine Reihe von Filtern für Ereignisse ist. Eine Regel folgt einem **Ereignismuster** oder den Metadaten der Statusänderung eines Ereignisses (ID, Region, Kontonummer, ARN (s) usw.). Wenn ein Ereignis mit dem Ereignismuster übereinstimmt, EventBridge wird das Ereignis über die Pipeline an den **Zieldienst (Ziel**) gesendet und die in der Regel angegebene Aktion ausgelöst.

EventBridge eignet sich gut für die Weiterleitung von Zustandsänderungsvorgängen an einen anderen Dienst. Nehmen Sie diesen [Anwendungsfall](https://aws.amazon.com/blogs/mobile/appsync-eventbridge/) aus dem *Frontend-Blog für Web und Mobilgeräte*. Das Beispiel zeigt eine E-Commerce-Lösung, bei der mehrere Teams unterschiedliche Dienste verwalten. Einer dieser Dienste bietet dem Kunden bei jedem Schritt der Lieferung (Bestellung aufgegeben, in Bearbeitung, versendet, geliefert usw.) über das Frontend aktuelle Informationen zur Bestellung. Das Frontend-Team, das diesen Service verwaltet, hat jedoch keinen direkten Zugriff auf die Daten des Bestellsystems, da diese von einem separaten Backend-Team verwaltet werden. Das Bestellsystem des Backend-Teams wird auch als Blackbox beschrieben, sodass es schwierig ist, Informationen darüber zu erhalten, wie sie ihre Daten strukturieren. Das Backend-Team hat jedoch ein System eingerichtet, das Bestelldaten über einen Event-Bus veröffentlichte, der von verwaltet wird. EventBridge Um auf die vom Event-Bus kommenden Daten zuzugreifen und sie an das Front-End weiterzuleiten, erstellte das Front-End-Team ein neues Ziel, das auf die darin befindliche GraphQL-API verweist. AWS AppSync Außerdem wurde eine Regel erstellt, nach der nur Daten gesendet werden, die für die Aktualisierung der Bestellung relevant sind. Wenn ein Update durchgeführt wird, werden die Daten vom Event-Bus an die GraphQL-API gesendet. Das Schema in der API verarbeitet die Daten und leitet sie dann an das Frontend weiter.

### Keine Datenquellen
<a name="data-source-type-none"></a>

Wenn Sie nicht vorhaben, eine Datenquelle zu verwenden, können Sie sie auf einstellen`none`. Eine `none` Datenquelle ist zwar immer noch explizit als Datenquelle kategorisiert, aber kein Speichermedium. In der Regel ruft ein Resolver irgendwann eine oder mehrere Datenquellen auf, um die Anfrage zu verarbeiten. Es gibt jedoch Situationen, in denen Sie eine Datenquelle möglicherweise nicht manipulieren müssen. Wenn Sie die Datenquelle auf einstellen, `none` wird die Anfrage ausgeführt, der Datenaufruf-Schritt übersprungen und dann die Antwort ausgeführt.

Nehmen Sie denselben [Anwendungsfall](https://aws.amazon.com/blogs/mobile/appsync-eventbridge/) aus dem EventBridge Abschnitt. Im Schema verarbeitet die Mutation die Statusmeldung und sendet sie dann an die Abonnenten. Erinnert man sich daran, wie Resolver funktionieren, gibt es in der Regel mindestens einen Datenquellenaufruf. Die Daten in diesem Szenario wurden jedoch bereits automatisch vom Event-Bus gesendet. Das bedeutet, dass die Mutation nicht erforderlich ist, um einen Datenquellenaufruf durchzuführen. Der Auftragsstatus kann einfach lokal bearbeitet werden. Die Mutation ist auf gesetzt`none`, was als Pass-Through-Wert ohne Datenquellenaufruf fungiert. Das Schema wird dann mit den Daten gefüllt, die an Abonnenten gesendet werden.

### OpenSearch
<a name="data-source-type-opensearch"></a>

Amazon OpenSearch Service ist eine Suite von Tools zur Implementierung von Volltextsuche, Datenvisualisierung und Protokollierung. Sie können diesen Service verwenden, um die von Ihnen hochgeladenen strukturierten Daten abzufragen.

In diesem Service erstellen Sie Instanzen von OpenSearch. Diese werden **Knoten** genannt. In einem Knoten fügen Sie mindestens einen **Index** hinzu. Indizes sind konzeptionell ein bisschen wie Tabellen in relationalen Datenbanken. ( OpenSearch Ist jedoch nicht ACID-konform und sollte daher nicht auf diese Weise verwendet werden). Sie füllen Ihren Index mit Daten, die Sie in den OpenSearch Service hochladen. Wenn Ihre Daten hochgeladen werden, werden sie in einem oder mehreren Shards indexiert, die im Index vorhanden sind. Ein **Shard** ist wie eine Partition Ihres Indexes, die einige Ihrer Daten enthält und getrennt von anderen Shards abgefragt werden kann. **Nach dem Hochladen werden Ihre Daten als JSON-Dateien, sogenannte Dokumente, strukturiert.** Anschließend können Sie den Knoten nach Daten im Dokument abfragen.

### HTTP-Endpunkte
<a name="data-source-type-http"></a>

Sie können HTTP-Endpunkte als Datenquellen verwenden. AWS AppSync kann Anfragen mit den relevanten Informationen wie Parametern und Nutzdaten an die Endpunkte senden. Die HTTP-Antwort wird dem Resolver zugänglich gemacht, der die endgültige Antwort zurückgibt, nachdem er seine Operation (en) abgeschlossen hat.

## Eine Datenquelle hinzufügen
<a name="adding-a-data-source"></a>

Wenn Sie eine Datenquelle erstellt haben, können Sie sie mit dem AWS AppSync Dienst und insbesondere mit der API verknüpfen.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie Ihre API im **Dashboard** aus.

   1. Wählen Sie in der **Seitenleiste** **Datenquellen** aus.

1. Klicken Sie auf **Create data source**.

   1. Geben Sie Ihrer Datenquelle einen Namen. Sie können ihr auch eine Beschreibung geben, aber das ist optional.

   1. Wählen Sie Ihren **Datenquellentyp**.

   1. Für DynamoDB müssen Sie Ihre Region und dann die Tabelle in der Region auswählen. Sie können Interaktionsregeln für Ihre Tabelle vorschreiben, indem Sie eine neue generische Tabellenrolle erstellen oder eine bestehende Rolle für die Tabelle importieren. Sie können die [Versionsverwaltung](https://docs.aws.amazon.com/appsync/latest/devguide/conflict-detection-and-sync.html) aktivieren, sodass automatisch Datenversionen für jede Anfrage erstellt werden, wenn mehrere Clients versuchen, Daten gleichzeitig zu aktualisieren. Die Versionierung wird verwendet, um mehrere Datenvarianten zur Konflikterkennung und Konfliktlösung aufzubewahren und zu pflegen. Sie können auch die automatische Schemagenerierung aktivieren, bei der anhand Ihrer Datenquelle einige der CRUD- und `Query` Operationen generiert werden`List`, die für den Zugriff auf diese Daten in Ihrem Schema erforderlich sind. 

      Dafür OpenSearch müssen Sie Ihre Region und dann die Domain (Cluster) in der Region auswählen. Sie können Interaktionsregeln mit Ihrer Domain diktieren, indem Sie eine neue generische Tabellenrolle erstellen oder eine bestehende Rolle für die Tabelle importieren. 

      Für Lambda müssen Sie Ihre Region und dann den ARN der Lambda-Funktion in der Region auswählen. Sie können Interaktionsregeln mit Ihrer Lambda-Funktion diktieren, indem Sie eine neue generische Tabellenrolle erstellen oder eine vorhandene Rolle für die Tabelle importieren. 

      Für HTTP müssen Sie Ihren HTTP-Endpunkt eingeben.

      Dafür EventBridge müssen Sie Ihre Region und dann den Event-Bus in der Region auswählen. Sie können Interaktionsregeln mit Ihrem Event-Bus vorschreiben, indem Sie eine neue generische Tabellenrolle erstellen oder eine bestehende Rolle für die Tabelle importieren. 

      Für RDS müssen Sie Ihre Region, dann den geheimen Speicher (Benutzername und Passwort), den Datenbanknamen und das Schema auswählen.

      Für keine Daten fügen Sie eine Datenquelle ohne tatsächliche Datenquelle hinzu. Dies dient dazu, Resolver lokal und nicht über eine tatsächliche Datenquelle zu verarbeiten.
**Anmerkung**  
Wenn Sie vorhandene Rollen importieren, benötigen sie eine Vertrauensrichtlinie. Weitere Informationen finden Sie in der [IAM-Vertrauensrichtlinie](#iam-trust-policy.title).

1. Wählen Sie **Erstellen** aus.
**Anmerkung**  
Wenn Sie eine DynamoDB-Datenquelle erstellen, können Sie alternativ zur **Schemaseite** in der Konsole gehen, oben auf der Seite **Ressourcen erstellen** auswählen und dann ein vordefiniertes Modell ausfüllen, das in eine Tabelle umgewandelt werden soll. Bei dieser Option füllen Sie den Basistyp aus oder importieren ihn, konfigurieren die grundlegenden Tabellendaten einschließlich des Partitionsschlüssels und überprüfen die Schemaänderungen.

------
#### [ CLI ]
+ Erstellen Sie Ihre Datenquelle, indem Sie den [https://docs.aws.amazon.com/cli/latest/reference/appsync/create-data-source.html](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-data-source.html)Befehl ausführen.

  Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Die `name` deines Tisches.

  1. Die `type` der Datenquelle. Je nach ausgewähltem Datenquellentyp müssen Sie möglicherweise ein Tag `service-role-arn` und ein `-config` Tag eingeben.

  Ein Beispielbefehl könnte wie folgt aussehen:

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

------
#### [ CDK ]

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.

Um Ihre spezielle Datenquelle hinzuzufügen, müssen Sie das Konstrukt zu Ihrer Stack-Datei hinzufügen. Eine Liste der Datenquellentypen finden Sie hier:
+  [ DynamoDbDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.DynamoDbDataSource.html) 
+  [ EventBridgeDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.EventBridgeDataSource.html) 
+  [ HttpDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.HttpDataSource.html) 
+  [ LambdaDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.LambdaDataSource.html) 
+  [ NoneDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.NoneDataSource.html) 
+  [ OpenSearchDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.OpenSearchDataSource.html) 
+  [ RdsDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.RdsDataSource.html) 

1. Im Allgemeinen müssen Sie möglicherweise die Import-Direktive zu dem Dienst hinzufügen, den Sie verwenden. Zum Beispiel kann es den folgenden Formen folgen:

   ```
   import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
   import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'
   ```

   So könnten Sie beispielsweise die Dienste AWS AppSync und DynamoDB importieren:

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

1. Einige Dienste wie RDS erfordern einige zusätzliche Einstellungen in der Stack-Datei, bevor die Datenquelle erstellt wird (z. B. VPC-Erstellung, Rollen und Zugangsdaten). Weitere Informationen finden Sie in den Beispielen auf den entsprechenden CDK-Seiten.

1. Für die meisten Datenquellen, insbesondere AWS Dienste, erstellen Sie eine neue Instanz der Datenquelle in Ihrer Stack-Datei. In der Regel sieht das wie folgt aus:

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

   Hier ist zum Beispiel ein Beispiel für eine Amazon DynamoDB-Tabelle:

   ```
   const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
     partitionKey: {
       name: 'id',
       type: dynamodb.AttributeType.STRING,
     },
     sortKey: {
       name: 'id',
       type: dynamodb.AttributeType.STRING,
     },
     tableClass: dynamodb.TableClass.STANDARD,
   });
   ```
**Anmerkung**  
**Für die meisten Datenquellen ist mindestens eine Requisite erforderlich (wird ohne Symbol gekennzeichnet).** `?` Schlagen Sie in der CDK-Dokumentation nach, welche Requisiten benötigt werden.

1. Als Nächstes müssen Sie die Datenquelle mit der GraphQL-API verknüpfen. Die empfohlene Methode besteht darin, sie hinzuzufügen, wenn Sie eine Funktion für Ihren Pipeline-Resolver erstellen. Das folgende Snippet ist beispielsweise eine Funktion, die alle Elemente in einer DynamoDB-Tabelle scannt:

   ```
   const add_func = new appsync.AppsyncFunction(this, 'func_ID', {
     name: 'func_name_in_console',
     add_api,
     dataSource: add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table),
     code: appsync.Code.fromInline(`
         export function request(ctx) {
           return { operation: 'Scan' };
         }
   
         export function response(ctx) {
           return ctx.result.items;
         }
     `),
     runtime: appsync.FunctionRuntime.JS_1_0_0,
   });
   ```

   In den `dataSource` Requisiten können Sie die GraphQL-API (`add_api`) aufrufen und eine der integrierten Methoden (`addDynamoDbDataSource`) verwenden, um die Verknüpfung zwischen der Tabelle und der GraphQL-API herzustellen. Die Argumente sind der Name dieses Links, der in der AWS AppSync Konsole existieren wird (`data_source_name_in_console`in diesem Beispiel), und die Tabellenmethode (). `add_ddb_table` Mehr zu diesem Thema erfahren Sie im nächsten Abschnitt, wenn Sie mit der Erstellung von Resolvern beginnen.

   Es gibt alternative Methoden zum Verknüpfen einer Datenquelle. Technisch gesehen könnten Sie `api` die Requisitenliste in der Tabellenfunktion erweitern. Hier ist zum Beispiel der Ausschnitt aus Schritt 3, aber mit `api` Requisiten, die eine GraphQL-API enthalten:

   ```
   const add_api = new appsync.GraphqlApi(this, 'API_ID', {
     ...
   });
   
   const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
   
    ...
   
     api: add_api
   });
   ```

   Alternativ können Sie das Konstrukt separat aufrufen: `GraphqlApi`

   ```
   const add_api = new appsync.GraphqlApi(this, 'API_ID', {
     ...
   });
   
   const add_ddb_table = new dynamodb.Table(this, 'Table_ID', {
     ...
   });
   
   const link_data_source = add_api.addDynamoDbDataSource('data_source_name_in_console', add_ddb_table);
   ```

   Wir empfehlen, die Assoziation nur in den Requisiten der Funktion zu erstellen. Andernfalls müssen Sie entweder Ihre Resolverfunktion manuell in der Konsole mit der Datenquelle verknüpfen (wenn Sie den AWS AppSync Konsolenwert weiterhin verwenden möchten`data_source_name_in_console`) oder eine separate Zuordnung in der Funktion unter einem anderen Namen wie erstellen. `data_source_name_in_console_2` Dies ist auf Einschränkungen bei der Verarbeitung von Informationen durch die Requisiten zurückzuführen.
**Anmerkung**  
Sie müssen die App erneut bereitstellen, um Ihre Änderungen zu sehen.

------

### IAM-Vertrauensrichtlinie
<a name="iam-trust-policy"></a>

Wenn Sie eine bestehende IAM-Rolle für Ihre Datenquelle verwenden, müssen Sie dieser Rolle die entsprechenden Berechtigungen gewähren, um Operationen an Ihrer AWS Ressource, z. B. `PutItem` an einer Amazon DynamoDB-Tabelle, durchzuführen. Sie müssen auch die Vertrauensrichtlinie für diese Rolle ändern, damit sie für den AWS AppSync Ressourcenzugriff verwendet werden kann, wie in der folgenden Beispielrichtlinie dargestellt:

------
#### [ JSON ]

****  

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

------

Sie können Ihrer Vertrauensrichtlinie auch Bedingungen hinzufügen, um den Zugriff auf die Datenquelle nach Bedarf einzuschränken. Derzeit `SourceArn` können unter diesen Bedingungen auch `SourceAccount` Schlüssel verwendet werden. Beispielsweise beschränkt die folgende Richtlinie den Zugriff auf Ihre Datenquelle auf das Konto`123456789012`:

------
#### [ JSON ]

****  

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

------

Alternativ können Sie den Zugriff auf eine Datenquelle auf eine bestimmte API beschränken, z. B. `abcdefghijklmnopq` mithilfe der folgenden Richtlinie:

------
#### [ JSON ]

****  

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

------

Sie können den Zugriff auf alle AWS AppSync APIs Benutzer aus einer bestimmten Region einschränken`us-east-1`, z. B. mithilfe der folgenden Richtlinie:

------
#### [ JSON ]

****  

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

------

Im nächsten Abschnitt ([Konfiguration von Resolvern](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-config-overview.html)) fügen wir unsere Resolver-Geschäftslogik hinzu und hängen sie an die Felder in unserem Schema an, um die Daten in unserer Datenquelle zu verarbeiten.

Weitere Informationen zur Konfiguration von Rollenrichtlinien finden Sie unter [Ändern einer Rolle](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_manage_modify.html) im *IAM-Benutzerhandbuch*.

Weitere Informationen zum kontoübergreifenden Zugriff auf AWS Lambda Resolver für finden Sie unter [Kontenübergreifende AWS Lambda Resolver für AWS AppSync erstellen](https://aws.amazon.com/blogs/mobile/appsync-lambda-cross-account/). AWS AppSync

# Resolver konfigurieren in AWS AppSync
<a name="resolver-config-overview"></a>

In den vorherigen Abschnitten haben Sie gelernt, wie Sie Ihr GraphQL-Schema und Ihre Datenquelle erstellen und diese dann im AWS AppSync Service miteinander verknüpft haben. In Ihrem Schema haben Sie möglicherweise ein oder mehrere Felder (Operationen) in Ihrer Abfrage und Mutation eingerichtet. Das Schema beschrieb zwar die Arten von Daten, die die Operationen von der Datenquelle anfordern würden, es wurde jedoch nie implementiert, wie sich diese Operationen in Bezug auf die Daten verhalten würden. 

Das Verhalten einer Operation wird immer im Resolver implementiert, der mit dem Feld verknüpft wird, das die Operation ausführt. Weitere Informationen zur Funktionsweise von Resolvern im Allgemeinen finden Sie auf der [Resolver-Seite](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html).

In AWS AppSync ist Ihr Resolver an eine Runtime gebunden, das ist die Umgebung, in der Ihr Resolver ausgeführt wird. Laufzeiten bestimmen die Sprache, in der Ihr Resolver geschrieben wird. Derzeit werden zwei Laufzeiten unterstützt: APPSYNC\$1JS (JavaScript) und Apache Velocity Template Language (VTL). 

Bei der Implementierung von Resolvern gibt es eine allgemeine Struktur, der sie folgen:
+ **Schritt vor dem**: Wenn eine Anfrage vom Client gestellt wird, werden den Resolvern für die verwendeten Schemafelder (normalerweise Ihre Abfragen, Mutationen, Abonnements) die Anforderungsdaten übergeben. Der Resolver beginnt mit der Verarbeitung der Anforderungsdaten mit einem Before-Step-Handler, der es ermöglicht, einige Vorverarbeitungsvorgänge durchzuführen, bevor die Daten den Resolver passieren.
+ **Funktion (en)**: Nachdem der vorherige Schritt ausgeführt wurde, wird die Anforderung an die Funktionsliste übergeben. Die erste Funktion in der Liste wird für die Datenquelle ausgeführt. Eine Funktion ist eine Teilmenge des Codes Ihres Resolvers, die einen eigenen Anfrage- und Antworthandler enthält. Ein Anforderungshandler nimmt die Anforderungsdaten und führt Operationen an der Datenquelle durch. Der Antworthandler verarbeitet die Antwort der Datenquelle, bevor er sie an die Liste zurückgibt. Wenn es mehr als eine Funktion gibt, werden die Anforderungsdaten zur Ausführung an die nächste Funktion in der Liste gesendet. Die Funktionen in der Liste werden seriell in der vom Entwickler festgelegten Reihenfolge ausgeführt. Sobald alle Funktionen ausgeführt wurden, wird das Endergebnis an den nächsten Schritt übergeben.
+ **Nach dem Schritt**: Der Nachschritt ist eine Handler-Funktion, mit der Sie einige letzte Operationen an der Antwort der endgültigen Funktion ausführen können, bevor Sie sie an die GraphQL-Antwort übergeben.

Dieser Flow ist ein Beispiel für einen Pipeline-Resolver. Pipeline-Resolver werden in beiden Laufzeiten unterstützt. Dies ist jedoch eine vereinfachte Erklärung dessen, was Pipeline-Resolver leisten können. Außerdem beschreiben wir nur eine mögliche Resolver-Konfiguration. [Weitere Informationen zu unterstützten Resolver-Konfigurationen finden Sie in der [Resolver-Übersicht für APPSYNC\$1JS oder in der Übersicht über JavaScript Resolver-Mapping-Vorlagen](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html) für VTL.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-overview.html)

Wie Sie sehen können, sind Resolver modular aufgebaut. Damit die Komponenten des Resolvers ordnungsgemäß funktionieren, müssen sie in der Lage sein, von anderen Komponenten aus auf den Status der Ausführung zuzugreifen. Aus dem Abschnitt [Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html) wissen Sie, dass jeder Komponente im Resolver wichtige Informationen über den Status der Ausführung als Satz von Argumenten (`args``context`, usw.) übergeben werden können. Darin wird AWS AppSync dies ausschließlich von der abgewickelt. `context` Es ist ein Container für die Informationen über das Feld, das aufgelöst wird. Dies kann alles beinhalten, von übergebenen Argumenten über Ergebnisse bis hin zu Autorisierungsdaten, Header-Daten usw. Weitere Informationen zum Kontext finden Sie in der [Resolver-Kontext-Objektreferenz für APPSYNC\$1JS oder in der Kontextreferenz](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) für [Resolver-Mapping-Vorlagen](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html) für VTL.

Der Kontext ist nicht das einzige Tool, mit dem Sie Ihren Resolver implementieren können. AWS AppSync unterstützt eine Vielzahl von Hilfsprogrammen für die Wertgenerierung, Fehlerbehandlung, Analyse, Konvertierung usw. [Eine Liste der Dienstprogramme finden Sie [hier](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference-js.html) für APPSYNC\$1JS oder hier für VTL.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-util-reference.html)

In den folgenden Abschnitten erfahren Sie, wie Sie Resolver in Ihrer GraphQL-API konfigurieren.

**Topics**
+ [Einfache Abfragen erstellen (JavaScript)](configuring-resolvers-js.md)
+ [Basisabfragen erstellen (VTL)](configuring-resolvers.md)

# Einfache Abfragen erstellen (JavaScript)
<a name="configuring-resolvers-js"></a>

GraphQL-Resolver verbinden die Felder in einem Schema mit einer Datenquelle. Resolver sind der Mechanismus, mit dem Anfragen erfüllt werden.

Resolver, die AWS AppSync verwendet werden JavaScript , um einen GraphQL-Ausdruck in ein Format zu konvertieren, das die Datenquelle verwenden kann. Alternativ können Mapping-Vorlagen in [Apache Velocity Template Language (VTL)](https://velocity.apache.org/engine/2.0/vtl-reference.html) geschrieben werden, um einen GraphQL-Ausdruck in ein Format zu konvertieren, das die Datenquelle verwenden kann.

In diesem Abschnitt wird beschrieben, wie Resolver mithilfe von konfiguriert werden. JavaScript Der Abschnitt [Resolver-Tutorials (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/tutorials-js.html) enthält ausführliche Anleitungen zur Implementierung von Resolvern mithilfe von. JavaScript Der Abschnitt [Resolver-Referenz (JavaScript)](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html) enthält eine Erläuterung der Hilfsoperationen, die mit Resolvern verwendet werden können. JavaScript 

Wir empfehlen, diese Anleitung zu befolgen, bevor Sie versuchen, eines der oben genannten Tutorials zu verwenden.

In diesem Abschnitt werden wir uns mit der Erstellung und Konfiguration von Resolvern für Abfragen und Mutationen befassen.

**Anmerkung**  
In diesem Handbuch wird davon ausgegangen, dass Sie Ihr Schema erstellt haben und mindestens eine Abfrage oder Mutation haben. Wenn Sie nach Abonnements (Echtzeitdaten) suchen, lesen Sie [diese](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html) Anleitung.

In diesem Abschnitt finden Sie einige allgemeine Schritte zur Konfiguration von Resolvern sowie ein Beispiel, das das folgende Schema verwendet:

```
// schema.graphql file

input CreatePostInput {
  title: String
  date: AWSDateTime
}

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

type Mutation {
  createPost(input: CreatePostInput!): Post
}

type Query {
  getPost: [Post]
}
```

## Einfache Abfragerolver erstellen
<a name="create-basic-query-resolver-js"></a>

In diesem Abschnitt erfahren Sie, wie Sie einen einfachen Abfrageauflöser erstellen.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. Geben Sie die Details Ihres Schemas und Ihrer Datenquelle ein. Weitere Informationen finden Sie in den Abschnitten [Entwerfen Ihres Schemas](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) und [Anhängen einer Datenquelle](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html).

1. Neben dem **Schema-Editor** befindet sich ein Fenster mit dem Namen **Resolvers**. Dieses Feld enthält eine Liste der Typen und Felder, wie sie in Ihrem **Schemafenster** definiert sind. Sie können Resolver an Felder anhängen. Höchstwahrscheinlich werden Sie Resolver an Ihre Feldoperationen anhängen. In diesem Abschnitt werden wir uns einfache Abfragekonfigurationen ansehen. Wählen Sie unter dem **Abfragetyp** neben dem Feld Ihrer Abfrage die Option **Anhängen** aus.

1. Auf der Seite **Resolver anhängen** können Sie unter **Resolvertyp** zwischen Pipeline- und Unit-Resolvern wählen. [Weitere Informationen zu diesen Typen finden Sie unter Resolver.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html) In diesem Handbuch werden verwendet. `pipeline resolvers`
**Tipp**  
Bei der Erstellung von Pipeline-Resolvern werden Ihre Datenquellen an die Pipeline-Funktion (en) angehängt. Funktionen werden erstellt, nachdem Sie den Pipeline-Resolver selbst erstellt haben. Aus diesem Grund gibt es auf dieser Seite keine Option, sie festzulegen. Wenn Sie einen Unit-Resolver verwenden, ist die Datenquelle direkt mit dem Resolver verknüpft, sodass Sie sie auf dieser Seite einstellen würden.

   Wählen Sie für die **Resolver-Runtime**, ob Sie `APPSYNC_JS` die Laufzeit aktivieren möchten. JavaScript 

1. Sie können das [Caching](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) für diese API aktivieren. Wir empfehlen, diese Funktion vorerst auszuschalten. Wählen Sie **Erstellen** aus.

1. Auf der Seite **Resolver bearbeiten** gibt es einen Code-Editor namens **Resolver-Code**, mit dem Sie die Logik für den Resolver-Handler und die Antwort (vor und nach den Schritten) implementieren können. [Weitere Informationen finden Sie in der Übersicht über die JavaScript Resolver.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html) 
**Anmerkung**  
In unserem Beispiel lassen wir die Anfrage einfach leer und die Antwort wird so eingestellt, dass sie das letzte Datenquellenergebnis aus dem [Kontext](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) zurückgibt:  

   ```
   import {util} from '@aws-appsync/utils';
   
   export function request(ctx) {
       return {};
   }
   
   export function response(ctx) {
       return ctx.prev.result;
   }
   ```

   Unterhalb dieses Abschnitts befindet sich eine Tabelle mit dem Namen **Functions**. Mit Funktionen können Sie Code implementieren, der für mehrere Resolver wiederverwendet werden kann. Anstatt Code ständig neu zu schreiben oder zu kopieren, können Sie den Quellcode als Funktion speichern, die Sie einem Resolver hinzufügen können, wann immer Sie ihn benötigen. 

   Funktionen machen den Großteil der Operationsliste einer Pipeline aus. Wenn Sie mehrere Funktionen in einem Resolver verwenden, legen Sie die Reihenfolge der Funktionen fest, und sie werden nacheinander in dieser Reihenfolge ausgeführt. Sie werden ausgeführt, nachdem die Anforderungsfunktion ausgeführt wurde und bevor die Antwortfunktion beginnt.

   Um eine neue Funktion hinzuzufügen, wählen Sie unter **Funktionen** die Option **Funktion hinzufügen** und dann **Neue Funktion erstellen** aus. Alternativ wird Ihnen möglicherweise die Schaltfläche **Funktion erstellen** angezeigt, aus der Sie stattdessen auswählen können.

   1. Wählen Sie eine Datenquelle aus. Dies wird die Datenquelle sein, auf die der Resolver reagiert.
**Anmerkung**  
In unserem Beispiel hängen wir einen Resolver für an`getPost`, der ein Objekt von abruft. `Post` `id` Nehmen wir an, wir haben bereits eine DynamoDB-Tabelle für dieses Schema eingerichtet. Ihr Partitionsschlüssel ist auf „gesetzt“ `id` und leer.

   1. Geben Sie ein`Function name`.

   1. Unter **Funktionscode** müssen Sie das Verhalten der Funktion implementieren. Das mag verwirrend sein, aber jede Funktion wird ihren eigenen lokalen Anfrage- und Antworthandler haben. Die Anforderung wird ausgeführt, dann erfolgt der Datenquellenaufruf, um die Anfrage zu bearbeiten, und dann wird die Datenquellenantwort vom Antworthandler verarbeitet. Das Ergebnis wird im [Kontextobjekt](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) gespeichert. Danach wird die nächste Funktion in der Liste ausgeführt oder an den Antworthandler nach dem Schritt übergeben, falls es sich um die letzte handelt. 
**Anmerkung**  
In unserem Beispiel hängen wir einen Resolver an`getPost`, der eine Liste von `Post` Objekten aus der Datenquelle erhält. Unsere Anforderungsfunktion fordert die Daten aus unserer Tabelle an, die Tabelle leitet ihre Antwort an den Kontext weiter (ctx), dann gibt die Antwort das Ergebnis im Kontext zurück. AWS AppSync Die Stärke liegt in der Vernetzung mit anderen Diensten. AWS Da wir DynamoDB verwenden, verfügen wir über eine [Reihe von Operationen](https://docs.aws.amazon.com/appsync/latest/devguide/js-resolver-reference-dynamodb.html), um solche Dinge zu vereinfachen. Wir haben auch einige Standardbeispiele für andere Datenquellentypen.  
Unser Code wird so aussehen:  

      ```
      import { util } from '@aws-appsync/utils';
      
      /**
       * Performs a scan on the dynamodb data source
       */
      export function request(ctx) {
        return { operation: 'Scan' };
      }
      
      /**
       * return a list of scanned post items
       */
      export function response(ctx) {
        return ctx.result.items;
      }
      ```
In diesem Schritt haben wir zwei Funktionen hinzugefügt:  
`request`: Der Anforderungshandler führt den Abrufvorgang für die Datenquelle aus. Das Argument enthält das Kontextobjekt (`ctx`) oder einige Daten, die allen Resolvern zur Verfügung stehen, die eine bestimmte Operation ausführen. Es kann beispielsweise Autorisierungsdaten, die aufgelösten Feldnamen usw. enthalten. Die Return-Anweisung führt eine [https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-scan](https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-scan)Operation aus (Beispiele finden Sie [hier](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html)). Da wir mit DynamoDB arbeiten, dürfen wir einige der Operationen dieses Dienstes verwenden. Der Scan führt einen einfachen Abruf aller Elemente in unserer Tabelle durch. Das Ergebnis dieser Operation wird im Kontextobjekt als `result` Container gespeichert, bevor es an den Antworthandler übergeben wird. Das `request` wird vor der Antwort in der Pipeline ausgeführt.
`response`: Der Antworthandler, der die Ausgabe von zurückgibt`request`. Das Argument ist das aktualisierte Kontextobjekt und die Rückgabeanweisung ist`ctx.prev.result`. Zu diesem Zeitpunkt in der Anleitung sind Sie mit diesem Wert möglicherweise noch nicht vertraut. `ctx`bezieht sich auf das Kontextobjekt. `prev`bezieht sich auf die vorherige Operation in der Pipeline, die unsere war`request`. Der `result` enthält die Ergebnisse des Resolvers, während er sich durch die Pipeline bewegt. Wenn Sie alles zusammenfügen, `ctx.prev.result` wird das Ergebnis der letzten ausgeführten Operation zurückgegeben, bei der es sich um den Request-Handler handelte.

   1. Wenn Sie fertig sind, wählen Sie **Create**.

1. Zurück auf dem Resolver-Bildschirm wählen Sie unter **Funktionen** das Drop-down-Menü **Funktion hinzufügen** und fügen Sie Ihre Funktion zu Ihrer Funktionsliste hinzu.

1. Wählen Sie **Speichern**, um den Resolver zu aktualisieren.

------
#### [ CLI ]

**Um Ihre Funktion hinzuzufügen**
+ Erstellen Sie mit dem `[create-function](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-function.html)` Befehl eine Funktion für Ihren Pipeline-Resolver.

  Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Die `name` der Funktion in der AWS AppSync Konsole.

  1. Der oder der Name der Datenquelle`data-source-name`, die die Funktion verwenden wird. Es muss bereits erstellt und mit Ihrer GraphQL-API im AWS AppSync Service verknüpft sein.

  1. Die `runtime` oder Umgebung und die Sprache der Funktion. Für JavaScript muss `APPSYNC_JS` der Name und die Laufzeit, lauten`1.0.0`.

  1. Die `code` oder Request- und Response-Handler Ihrer Funktion. Sie können es zwar manuell eingeben, es ist jedoch viel einfacher, es einer TXT-Datei (oder einem ähnlichen Format) hinzuzufügen und es dann als Argument zu übergeben. 
**Anmerkung**  
Unser Abfragecode wird in einer Datei gespeichert, die als Argument übergeben wird:  

     ```
     import { util } from '@aws-appsync/utils';
     
     /**
      * Performs a scan on the dynamodb data source
      */
     export function request(ctx) {
       return { operation: 'Scan' };
     }
     
     /**
      * return a list of scanned post items
      */
     export function response(ctx) {
       return ctx.result.items;
     }
     ```

  Ein Beispielbefehl könnte so aussehen:

  ```
  aws appsync create-function \
  --api-id abcdefghijklmnopqrstuvwxyz \
  --name get_posts_func_1 \
  --data-source-name table-for-posts \
  --runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
  --code file://~/path/to/file/{filename}.{fileType}
  ```

  Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

  ```
  {
      "functionConfiguration": {
          "functionId": "ejglgvmcabdn7lx75ref4qeig4",
          "functionArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/functions/ejglgvmcabdn7lx75ref4qeig4",
          "name": "get_posts_func_1",
          "dataSourceName": "table-for-posts",
          "maxBatchSize": 0,
          "runtime": {
              "name": "APPSYNC_JS",
              "runtimeVersion": "1.0.0"
          },
          "code": "Code output goes here"
      }
  }
  ```
**Anmerkung**  
Stellen Sie sicher, dass Sie `functionId` irgendwo aufzeichnen, da dies verwendet wird, um die Funktion an den Resolver anzuhängen.

**Um deinen Resolver zu erstellen**
+ Erstellen Sie eine Pipeline-Funktion für, `Query` indem Sie den `[create-resolver](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)` Befehl ausführen.

  Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Der `type-name` oder der spezielle Objekttyp in Ihrem Schema (Query, Mutation, Subscription).

  1. Die `field-name` oder die Feldoperation innerhalb des speziellen Objekttyps, an den Sie den Resolver anhängen möchten.

  1. Der`kind`, der einen Units- oder Pipeline-Resolver angibt. Stellen Sie diesen Wert auf ein, `PIPELINE` um Pipeline-Funktionen zu aktivieren.

  1. Die oder die Funktion (en)`pipeline-config`, die an den Resolver angehängt werden sollen. Stellen Sie sicher, dass Sie die `functionId` Werte Ihrer Funktionen kennen. Die Reihenfolge der Auflistung ist wichtig.

  1. Das`runtime`, was war `APPSYNC_JS` (JavaScript). Das ist `runtimeVersion` derzeit`1.0.0`.

  1. Der`code`, der die Vorher- und Nachher-Schritthandler enthält.
**Anmerkung**  
Unser Abfragecode wird in einer Datei gespeichert, die als Argument übergeben wird:  

     ```
     import { util } from '@aws-appsync/utils';
     
     /**
      * Sends a request to `put` an item in the DynamoDB data source
      */
     export function request(ctx) {
       const { id, ...values } = ctx.args;
       return {
         operation: 'PutItem',
         key: util.dynamodb.toMapValues({ id }),
         attributeValues: util.dynamodb.toMapValues(values),
       };
     }
     
     /**
      * returns the result of the `put` operation
      */
     export function response(ctx) {
       return ctx.result;
     }
     ```

  Ein Beispielbefehl könnte so aussehen:

  ```
  aws appsync create-resolver \
  --api-id abcdefghijklmnopqrstuvwxyz \
  --type-name Query \
  --field-name getPost \
  --kind PIPELINE \
  --pipeline-config functions=ejglgvmcabdn7lx75ref4qeig4 \
  --runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
  --code file:///path/to/file/{filename}.{fileType}
  ```

  Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

  ```
  {
      "resolver": {
          "typeName": "Mutation",
          "fieldName": "getPost",
          "resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation/resolvers/getPost",
          "kind": "PIPELINE",
          "pipelineConfig": {
              "functions": [
                  "ejglgvmcabdn7lx75ref4qeig4"
              ]
          },
          "maxBatchSize": 0,
          "runtime": {
              "name": "APPSYNC_JS",
              "runtimeVersion": "1.0.0"
          },
          "code": "Code output goes here"
      }
  }
  ```

------
#### [ CDK ]

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.

Eine Basis-App benötigt die folgenden Dinge:

1. Richtlinien für den Import von Diensten

1. Schemacode

1. Datenquellengenerator

1. Funktionscode

1. Resolver-Code

Aus den Abschnitten [Entwerfen Ihres Schemas](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) und [Anhängen einer Datenquelle](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) wissen wir, dass die Stack-Datei die Importanweisungen des Formulars enthalten wird:

```
import * as x from 'x'; # import wildcard as the 'x' keyword from 'x-service'
import {a, b, ...} from 'c'; # import {specific constructs} from 'c-service'
```

**Anmerkung**  
In den vorherigen Abschnitten haben wir nur erklärt, wie AWS AppSync Konstrukte importiert werden. In echtem Code müssen Sie mehr Dienste importieren, nur um die App auszuführen. Wenn wir in unserem Beispiel eine sehr einfache CDK-App erstellen würden, würden wir zumindest den AWS AppSync Service zusammen mit unserer Datenquelle importieren, bei der es sich um eine DynamoDB-Tabelle handelt. Wir müssten auch einige zusätzliche Konstrukte importieren, um die App bereitzustellen:  

```
import * as cdk from 'aws-cdk-lib';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';
```
Um jedes dieser Dinge zusammenzufassen:  
`import * as cdk from 'aws-cdk-lib';`: Auf diese Weise können Sie Ihre CDK-App und Konstrukte wie den Stack definieren. Es enthält auch einige nützliche Hilfsfunktionen für unsere Anwendung, wie z. B. die Manipulation von Metadaten. Wenn Sie mit dieser Importdirektive vertraut sind, sich aber fragen, warum die CDK-Kernbibliothek hier nicht verwendet wird, lesen Sie die [Migrationsseite](https://docs.aws.amazon.com/cdk/v2/guide/migrating-v2.html).
`import * as appsync from 'aws-cdk-lib/aws-appsync';`: Dadurch wird der [AWS AppSync Dienst](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) importiert.
`import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';`: Dadurch wird der [DynamoDB-Dienst](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_dynamodb-readme.html) importiert.
`import { Construct } from 'constructs';`[: Wir benötigen das, um das Root-Konstrukt zu definieren.](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html)

Die Art des Imports hängt von den Diensten ab, die Sie aufrufen. Wir empfehlen, in der CDK-Dokumentation nach Beispielen zu suchen. Das Schema oben auf der Seite wird eine separate Datei in Ihrer CDK-App als `.graphql` Datei sein. In der Stack-Datei können wir sie mit einem neuen GraphQL verknüpfen, indem wir das folgende Formular verwenden:

```
const add_api = new appsync.GraphqlApi(this, 'graphQL-example', {
  name: 'my-first-api',
  schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql')),
});
```

**Anmerkung**  
In diesem Bereich `add_api` fügen wir eine neue GraphQL-API hinzu, die das `new` Schlüsselwort gefolgt von `appsync.GraphqlApi(scope: Construct, id: string , props: GraphqlApiProps)` verwendet. Unser Geltungsbereich lautet`this`, die CFN-ID lautet`graphQL-example`, und unsere Requisiten sind `my-first-api` (Name der API in der Konsole) und `schema.graphql` (der absolute Pfad zur Schemadatei).

Um eine Datenquelle hinzuzufügen, müssen Sie zuerst Ihre Datenquelle zum Stack hinzufügen. Anschließend müssen Sie es mithilfe der quellenspezifischen Methode mit der GraphQL-API verknüpfen. Die Zuordnung erfolgt, wenn Sie Ihren Resolver zum Laufen bringen. Lassen Sie uns in der Zwischenzeit ein Beispiel verwenden, indem wir die DynamoDB-Tabelle wie folgt erstellen: `dynamodb.Table`

```
const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
  partitionKey: {
    name: 'id',
    type: dynamodb.AttributeType.STRING,
  },
});
```

**Anmerkung**  
Wenn wir dies in unserem Beispiel verwenden würden, würden wir eine neue DynamoDB-Tabelle mit der CFN-ID von `posts-table` und dem Partitionsschlüssel von hinzufügen. `id (S)`

Als Nächstes müssen wir unseren Resolver in der Stack-Datei implementieren. Hier ist ein Beispiel für eine einfache Abfrage, die nach allen Elementen in einer DynamoDB-Tabelle sucht:

```
const add_func = new appsync.AppsyncFunction(this, 'func-get-posts', {
  name: 'get_posts_func_1',
  add_api,
  dataSource: add_api.addDynamoDbDataSource('table-for-posts', add_ddb_table),
  code: appsync.Code.fromInline(`
      export function request(ctx) {
        return { operation: 'Scan' };
      }

      export function response(ctx) {
        return ctx.result.items;
      }
  `),
  runtime: appsync.FunctionRuntime.JS_1_0_0,
});

new appsync.Resolver(this, 'pipeline-resolver-get-posts', {
  add_api,
  typeName: 'Query',
  fieldName: 'getPost',
  code: appsync.Code.fromInline(`
      export function request(ctx) {
        return {};
      }

      export function response(ctx) {
        return ctx.prev.result;
      }
 `),
  runtime: appsync.FunctionRuntime.JS_1_0_0,
  pipelineConfig: [add_func],
});
```

**Anmerkung**  
Zuerst haben wir eine Funktion namens erstellt. `add_func` Diese Reihenfolge der Erstellung mag etwas kontraintuitiv erscheinen, aber Sie müssen die Funktionen in Ihrem Pipeline-Resolver erstellen, bevor Sie den Resolver selbst erstellen. Eine Funktion folgt der Form:  

```
AppsyncFunction(scope: Construct, id: string, props: AppsyncFunctionProps)
```
Unser Anwendungsbereich war`this`, unsere CFN-ID war`func-get-posts`, und unsere Requisiten enthielten die tatsächlichen Funktionsdetails. Zu den Requisiten gehörten:  
Die Funktion, die in `name` der AWS AppSync Konsole vorhanden sein wird (`get_posts_func_1`).
Die GraphQL-API, die wir zuvor erstellt haben (`add_api`).
Die Datenquelle; dies ist der Punkt, an dem wir die Datenquelle mit dem GraphQL-API-Wert verknüpfen und ihn dann an die Funktion anhängen. Wir nehmen die Tabelle, die wir erstellt haben (`add_ddb_table`) und hängen sie mit einer der `GraphqlApi` Methoden (`add_api`) an die GraphQL-API ([https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.GraphqlApi.html#addwbrdynamowbrdbwbrdatawbrsourceid-table-options](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.GraphqlApi.html#addwbrdynamowbrdbwbrdatawbrsourceid-table-options)) an. Der ID-Wert (`table-for-posts`) ist der Name der Datenquelle in der AWS AppSync Konsole. Eine Liste quellenspezifischer Methoden finden Sie auf den folgenden Seiten:  
[ DynamoDbDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.DynamoDbDataSource.html) 
 [ EventBridgeDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.EventBridgeDataSource.html) 
 [ HttpDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.HttpDataSource.html) 
 [ LambdaDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.LambdaDataSource.html) 
 [ NoneDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.NoneDataSource.html) 
 [ OpenSearchDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.OpenSearchDataSource.html) 
 [ RdsDataSource ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync.RdsDataSource.html) 
Der Code enthält die Request- und Response-Handler unserer Funktion, was ein einfaches Scannen und Zurückgeben ist.
Die Laufzeit gibt an, dass wir die APPSYNC\$1JS-Laufzeitversion 1.0.0 verwenden möchten. Beachten Sie, dass dies derzeit die einzige Version ist, die für APPSYNC\$1JS verfügbar ist.
Als Nächstes müssen wir die Funktion an den Pipeline-Resolver anhängen. Wir haben unseren Resolver mit der folgenden Form erstellt:  

```
Resolver(scope: Construct, id: string, props: ResolverProps)
```
Unser Umfang war`this`, unsere CFN-ID war`pipeline-resolver-get-posts`, und unsere Requisiten enthielten die tatsächlichen Funktionsdetails. Zu den Requisiten gehörten:  
Die GraphQL-API, die wir zuvor erstellt haben (`add_api`).
Der Name des speziellen Objekttyps; dies ist eine Abfrageoperation, also haben wir einfach den Wert `Query` hinzugefügt.
Der Feldname (`getPost`) ist der Name des Felds im Schema unter dem `Query` Typ.
Der Code enthält Ihre Vorher- und Nachher-Handler. Unser Beispiel gibt nur die Ergebnisse zurück, die sich im Kontext befanden, nachdem die Funktion ihre Operation ausgeführt hat.
Die Laufzeit gibt an, dass wir die APPSYNC\$1JS-Laufzeitversion 1.0.0 verwenden möchten. Beachten Sie, dass dies derzeit die einzige Version ist, die für APPSYNC\$1JS verfügbar ist.
Die Pipeline-Konfiguration enthält den Verweis auf die von uns erstellte Funktion (). `add_func`

------

Um zusammenzufassen, was in diesem Beispiel passiert ist: Sie haben eine AWS AppSync Funktion gesehen, die einen Anfrage- und Antworthandler implementiert hat. Die Funktion war für die Interaktion mit Ihrer Datenquelle verantwortlich. Der Anforderungshandler hat eine `Scan` Operation an gesendet und ihm mitgeteilt AWS AppSync, welche Operation mit Ihrer DynamoDB-Datenquelle ausgeführt werden soll. Der Antworthandler hat die Liste der Elemente () zurückgegeben. `ctx.result.items` Die Liste der Elemente wurde dann automatisch dem `Post` GraphQL-Typ zugeordnet. 

## Erstellung grundlegender Mutationslöser
<a name="creating-basic-mutation-resolvers-js"></a>

In diesem Abschnitt erfahren Sie, wie Sie einen einfachen Mutationslöser erstellen.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. Wählen Sie unter dem Abschnitt **Resolver** und dem **Mutationstyp** neben Ihrem Feld die Option **Anhängen** aus.
**Anmerkung**  
In unserem Beispiel hängen wir einen Resolver für an`createPost`, der unserer Tabelle ein `Post` Objekt hinzufügt. Nehmen wir an, wir verwenden dieselbe DynamoDB-Tabelle aus dem letzten Abschnitt. Ihr Partitionsschlüssel ist auf „gesetzt“ `id` und leer.

1. Wählen Sie auf der Seite **Attach Resolver** unter **Resolver-Typ** die Option. `pipeline resolvers` [Zur Erinnerung: Weitere Informationen zu Resolvern finden Sie hier.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html) Wählen Sie für **Resolver Runtime** aus, ob Sie `APPSYNC_JS` die Laufzeit aktivieren möchten. JavaScript 

1. Sie können das [Caching](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) für diese API aktivieren. Wir empfehlen, diese Funktion vorerst auszuschalten. Wählen Sie **Erstellen** aus.

1. Wähle „**Funktion hinzufügen**“ und dann „**Neue Funktion erstellen**“. Alternativ wird Ihnen möglicherweise die Schaltfläche **Funktion erstellen** angezeigt, aus der Sie stattdessen auswählen können.

   1. Wählen Sie Ihre -Datenquelle aus. Dies sollte die Quelle sein, deren Daten Sie mit der Mutation manipulieren werden.

   1. Geben Sie ein`Function name`.

   1. Unter **Funktionscode** müssen Sie das Verhalten der Funktion implementieren. Da es sich um eine Mutation handelt, führt die Anfrage idealerweise einen Vorgang zur Änderung des Zustands an der aufgerufenen Datenquelle durch. Das Ergebnis wird von der Antwortfunktion verarbeitet.
**Anmerkung**  
`createPost`fügt der Tabelle ein neues `Post` hinzu oder „fügt“ es mit unseren Parametern als Daten ein. Wir könnten so etwas hinzufügen:   

      ```
      import { util } from '@aws-appsync/utils';
      
      /**
       * Sends a request to `put` an item in the DynamoDB data source
       */
      export function request(ctx) {
        return {
          operation: 'PutItem',
          key: util.dynamodb.toMapValues({id: util.autoId()}),
          attributeValues: util.dynamodb.toMapValues(ctx.args.input),
        };
      }
      
      /**
       * returns the result of the `put` operation
       */
      export function response(ctx) {
        return ctx.result;
      }
      ```
In diesem Schritt haben wir `request` auch `response` Funktionen hinzugefügt:  
`request`: Der Request-Handler akzeptiert den Kontext als Argument. Die Return-Anweisung des Request-Handlers führt einen [https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-putitem](https://docs.aws.amazon.com//appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-putitem)Befehl aus, bei dem es sich um einen integrierten DynamoDB-Vorgang handelt (Beispiele finden Sie [hier](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-2.html) [oder hier](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html#WorkingWithItems.WritingData)). Der `PutItem` Befehl fügt unserer DynamoDB-Tabelle ein `Post` Objekt hinzu, indem er den `key` Partitionswert (automatisch generiert von`util.autoid()`) und `attributes` die Eingabe des Kontextarguments verwendet (dies sind die Werte, die wir in unserer Anfrage übergeben werden). Die `key` Feldargumente `attributes` sind `id` und sind die `date` `title` Feldargumente. Sie sind beide über den [https://docs.aws.amazon.com//appsync/latest/devguide/dynamodb-helpers-in-util-dynamodb-js.html#utility-helpers-in-toMap-js](https://docs.aws.amazon.com//appsync/latest/devguide/dynamodb-helpers-in-util-dynamodb-js.html#utility-helpers-in-toMap-js)Helper vorformatiert, um mit der DynamoDB-Tabelle zu arbeiten.
`response`: Die Antwort akzeptiert den aktualisierten Kontext und gibt das Ergebnis des Request-Handlers zurück.

   1. Wählen Sie **Create**, wenn Sie fertig sind.

1. Zurück auf dem Resolver-Bildschirm wählen Sie unter **Funktionen** das Drop-down-Menü **Funktion hinzufügen** und fügen Sie Ihre Funktion zu Ihrer Funktionsliste hinzu.

1. Wählen Sie **Speichern**, um den Resolver zu aktualisieren.

------
#### [ CLI ]

**Um Ihre Funktion hinzuzufügen**
+ Erstellen Sie mit dem `[create-function](https://docs.aws.amazon.com/cli/latest/reference/appsync/create-function.html)` Befehl eine Funktion für Ihren Pipeline-Resolver.

  Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Die `name` der Funktion in der AWS AppSync Konsole.

  1. Der oder der Name der Datenquelle`data-source-name`, die die Funktion verwenden wird. Es muss bereits erstellt und mit Ihrer GraphQL-API im AWS AppSync Service verknüpft sein.

  1. Die `runtime` oder Umgebung und die Sprache der Funktion. Für JavaScript muss `APPSYNC_JS` der Name und die Laufzeit, lauten`1.0.0`.

  1. Die `code` oder Request- und Response-Handler Ihrer Funktion. Sie können es zwar manuell eingeben, aber es ist viel einfacher, es einer TXT-Datei (oder einem ähnlichen Format) hinzuzufügen und es dann als Argument zu übergeben. 
**Anmerkung**  
Unser Abfragecode wird sich in einer Datei befinden, die als Argument übergeben wird:  

     ```
     import { util } from '@aws-appsync/utils';
     
     /**
      * Sends a request to `put` an item in the DynamoDB data source
      */
     export function request(ctx) {
       return {
         operation: 'PutItem',
         key: util.dynamodb.toMapValues({id: util.autoId()}),
         attributeValues: util.dynamodb.toMapValues(ctx.args.input),
       };
     }
     
     /**
      * returns the result of the `put` operation
      */
     export function response(ctx) {
       return ctx.result;
     }
     ```

  Ein Beispielbefehl könnte so aussehen:

  ```
  aws appsync create-function \
  --api-id abcdefghijklmnopqrstuvwxyz \
  --name add_posts_func_1 \
  --data-source-name table-for-posts \
  --runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
  --code file:///path/to/file/{filename}.{fileType}
  ```

  Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

  ```
  {
      "functionConfiguration": {
          "functionId": "vulcmbfcxffiram63psb4dduoa",
          "functionArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/functions/vulcmbfcxffiram63psb4dduoa",
          "name": "add_posts_func_1",
          "dataSourceName": "table-for-posts",
          "maxBatchSize": 0,
          "runtime": {
              "name": "APPSYNC_JS",
              "runtimeVersion": "1.0.0"
          },
          "code": "Code output foes here"
      }
  }
  ```
**Anmerkung**  
Stellen Sie sicher, dass Sie `functionId` irgendwo aufzeichnen, da dies verwendet wird, um die Funktion an den Resolver anzuhängen.

**Um deinen Resolver zu erstellen**
+ Erstellen Sie eine Pipeline-Funktion für, `Mutation` indem Sie den `[create-resolver](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)` Befehl ausführen.

  Für diesen speziellen Befehl müssen Sie einige Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Der `type-name` oder der spezielle Objekttyp in Ihrem Schema (Query, Mutation, Subscription).

  1. Die `field-name` oder die Feldoperation innerhalb des speziellen Objekttyps, an den Sie den Resolver anhängen möchten.

  1. Der`kind`, der einen Units- oder Pipeline-Resolver angibt. Stellen Sie diesen Wert auf ein, `PIPELINE` um Pipeline-Funktionen zu aktivieren.

  1. Die oder die Funktion (en)`pipeline-config`, die an den Resolver angehängt werden sollen. Stellen Sie sicher, dass Sie die `functionId` Werte Ihrer Funktionen kennen. Die Reihenfolge der Auflistung ist wichtig.

  1. Das`runtime`, was war `APPSYNC_JS` (JavaScript). Das ist `runtimeVersion` derzeit`1.0.0`.

  1. Der`code`, der den Vorher-Nachher-Schritt enthält.
**Anmerkung**  
Unser Abfragecode wird in einer Datei enthalten sein, die als Argument übergeben wird:  

     ```
     import { util } from '@aws-appsync/utils';
     
     /**
      * Sends a request to `put` an item in the DynamoDB data source
      */
     export function request(ctx) {
       const { id, ...values } = ctx.args;
       return {
         operation: 'PutItem',
         key: util.dynamodb.toMapValues({ id }),
         attributeValues: util.dynamodb.toMapValues(values),
       };
     }
     
     /**
      * returns the result of the `put` operation
      */
     export function response(ctx) {
       return ctx.result;
     }
     ```

  Ein Beispielbefehl könnte so aussehen:

  ```
  aws appsync create-resolver \
  --api-id abcdefghijklmnopqrstuvwxyz \
  --type-name Mutation \
  --field-name createPost \
  --kind PIPELINE \
  --pipeline-config functions=vulcmbfcxffiram63psb4dduoa \
  --runtime name=APPSYNC_JS,runtimeVersion=1.0.0 \
  --code file:///path/to/file/{filename}.{fileType}
  ```

  Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

  ```
  {
      "resolver": {
          "typeName": "Mutation",
          "fieldName": "createPost",
          "resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Mutation/resolvers/createPost",
          "kind": "PIPELINE",
          "pipelineConfig": {
              "functions": [
                  "vulcmbfcxffiram63psb4dduoa"
              ]
          },
          "maxBatchSize": 0,
          "runtime": {
              "name": "APPSYNC_JS",
              "runtimeVersion": "1.0.0"
          },
          "code": "Code output goes here"
      }
  }
  ```

------
#### [ CDK ]

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/home.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Die unten aufgeführten Schritte zeigen nur ein allgemeines Beispiel für das Snippet, das zum Hinzufügen einer bestimmten Ressource verwendet wurde. Dies soll **keine** funktionierende Lösung in Ihrem Produktionscode sein. Wir gehen auch davon aus, dass Sie bereits eine funktionierende App haben.
+ Um eine Mutation vorzunehmen, können Sie, vorausgesetzt, Sie befinden sich im selben Projekt, diese wie die Abfrage zur Stack-Datei hinzufügen. Hier sind eine modifizierte Funktion und ein modifizierter Resolver für eine Mutation, die der Tabelle eine neue `Post` hinzufügen:

  ```
  const add_func_2 = new appsync.AppsyncFunction(this, 'func-add-post', {
    name: 'add_posts_func_1',
    add_api,
    dataSource: add_api.addDynamoDbDataSource('table-for-posts-2', add_ddb_table),
        code: appsync.Code.fromInline(`
            export function request(ctx) {
              return {
                operation: 'PutItem',
                key: util.dynamodb.toMapValues({id: util.autoId()}),
                attributeValues: util.dynamodb.toMapValues(ctx.args.input),
              };
            }
  
            export function response(ctx) {
              return ctx.result;
            }
        `), 
    runtime: appsync.FunctionRuntime.JS_1_0_0,
  });
  
  new appsync.Resolver(this, 'pipeline-resolver-create-posts', {
    add_api,
    typeName: 'Mutation',
    fieldName: 'createPost',
        code: appsync.Code.fromInline(`
            export function request(ctx) {
              return {};
            }
  
            export function response(ctx) {
              return ctx.prev.result;
            }
        `),
    runtime: appsync.FunctionRuntime.JS_1_0_0,
    pipelineConfig: [add_func_2],
  });
  ```
**Anmerkung**  
Da diese Mutation und die Abfrage ähnlich strukturiert sind, erläutern wir nur die Änderungen, die wir vorgenommen haben, um die Mutation vorzunehmen.   
In der Funktion haben wir die CFN-ID in `func-add-post` und den Namen in geändert, `add_posts_func_1` um der Tatsache Rechnung zu tragen, dass wir der Tabelle `Posts` etwas hinzufügen. In der Datenquelle haben wir eine neue Zuordnung zu unserer Tabelle (`add_ddb_table`) in der AWS AppSync Konsole vorgenommen, `table-for-posts-2` weil die `addDynamoDbDataSource` Methode dies erfordert. Denken Sie daran, dass diese neue Assoziation immer noch dieselbe Tabelle verwendet, die wir zuvor erstellt haben, aber wir haben jetzt zwei Verbindungen zu ihr in der AWS AppSync Konsole: eine für die Abfrage als `table-for-posts` und eine für die Mutation als`table-for-posts-2`. Der Code wurde dahingehend geändert, dass a hinzugefügt wurde, `Post` indem sein `id` Wert automatisch generiert wurde und die Eingabe eines Kunden für die restlichen Felder akzeptiert wurde.  
Im Resolver haben wir den ID-Wert in geändert, `pipeline-resolver-create-posts` um der Tatsache Rechnung zu tragen, dass wir der Tabelle `Posts` etwas hinzufügen. Um die Mutation im Schema widerzuspiegeln, wurde der Typname in`Mutation`, und der Name, `createPost` geändert. Die Pipeline-Konfiguration wurde auf unsere neue Mutationsfunktion eingestellt`add_func_2`.

------

Um zusammenzufassen, was in diesem Beispiel passiert: Konvertiert die in dem `createPost` Feld definierten Argumente AWS AppSync automatisch aus Ihrem GraphQL-Schema in DynamoDB-Operationen. Das Beispiel speichert Datensätze in DynamoDB mit dem Schlüssel von`id`, der automatisch mit unserem `util.autoId()` Helper erstellt wird. Alle anderen Felder, die Sie aus Anfragen in der AWS AppSync Konsole oder auf andere Weise an die Kontextargumente (`ctx.args.input`) übergeben, werden als Attribute der Tabelle gespeichert. Sowohl der Schlüssel als auch die Attribute werden mithilfe des Helpers automatisch einem kompatiblen DynamoDB-Format zugeordnet. `util.dynamodb.toMapValues(values)`

AWS AppSync unterstützt auch Test- und Debug-Workflows für die Bearbeitung von Resolvern. Sie können ein `context` Scheinobjekt verwenden, um den transformierten Wert der Vorlage zu sehen, bevor Sie sie aufrufen. Optional können Sie die vollständige Anfrage an eine Datenquelle interaktiv anzeigen, wenn Sie eine Abfrage ausführen. Weitere Informationen finden Sie unter [Resolver testen und debuggen (JavaScript) und [Überwachen](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html#aws-appsync-monitoring) und Protokollieren](https://docs.aws.amazon.com/appsync/latest/devguide/test-debug-resolvers-js.html).

## Fortgeschrittene Resolver
<a name="advanced-resolvers-js"></a>

Wenn Sie dem optionalen Abschnitt zur Paginierung unter [Ihr Schema entwerfen folgen, müssen Sie dennoch Ihren](designing-your-schema.md#aws-appsync-designing-your-schema) Resolver zu Ihrer Anfrage hinzufügen, um die Paginierung nutzen zu können. In unserem Beispiel wurde eine Abfrage-Paginierung verwendet`getPosts`, die aufgerufen wurde, um nur einen Teil der gleichzeitig angeforderten Dinge zurückzugeben. Der Code unseres Resolvers in diesem Feld könnte so aussehen:

```
/**
 * Performs a scan on the dynamodb data source
 */
export function request(ctx) {
  const { limit = 20, nextToken } = ctx.args;
  return { operation: 'Scan', limit, nextToken };
}

/**
 * @returns the result of the `put` operation
 */
export function response(ctx) {
  const { items: posts = [], nextToken } = ctx.result;
  return { posts, nextToken };
}
```

In der Anfrage geben wir den Kontext der Anfrage weiter. Unser `limit` ist*20*, was bedeutet, dass wir `Posts` bei der ersten Abfrage bis zu 20 zurückgeben. Unser `nextToken` Cursor ist auf den ersten `Post` Eintrag in der Datenquelle fixiert. Diese werden an die Argumente übergeben. Die Anfrage führt dann einen Scan von der ersten `Post` bis zur Anzahl der Scanlimits durch. Die Datenquelle speichert das Ergebnis im Kontext, der an die Antwort übergeben wird. Die Antwort gibt den `Posts` abgerufenen Wert zurück und setzt dann den `nextToken` Wert auf den `Post` Eintrag, der direkt hinter dem Grenzwert liegt. Die nächste Anfrage wird gesendet, um genau dasselbe zu tun, aber ab dem Offset direkt nach der ersten Abfrage. Denken Sie daran, dass diese Art von Anfragen sequentiell und nicht parallel ausgeführt werden.

# Resolver in AWS AppSync () testen und debuggen JavaScript
<a name="test-debug-resolvers-js"></a>

AWS AppSync führt Resolver in einem GraphQL-Feld gegen eine Datenquelle aus. Bei der Arbeit mit Pipeline-Resolvern interagieren Funktionen mit Ihren Datenquellen. Wie in der [Übersicht über JavaScript Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html) beschrieben, kommunizieren Funktionen mit Datenquellen, indem sie Anforderungs- und Antworthandler verwenden, die in der Laufzeit geschrieben sind JavaScript und dort ausgeführt werden. `APPSYNC_JS` Auf diese Weise können Sie vor und nach der Kommunikation mit der Datenquelle benutzerdefinierte Logik und Bedingungen bereitstellen.

Um Entwicklern beim Schreiben, Testen und Debuggen dieser Resolver zu helfen, bietet die AWS AppSync Konsole auch Tools zum Erstellen einer GraphQL-Anfrage und -Antwort mit Scheindaten bis hin zum einzelnen Field-Resolver. Darüber hinaus können Sie Abfragen, Mutationen und Abonnements in der AWS AppSync Konsole durchführen und einen detaillierten Protokollstream der gesamten Anfrage von Amazon einsehen CloudWatch. Dies schließt Ergebnisse aus der Datenquelle ein.

## Testen mit Scheindaten
<a name="testing-with-mock-data-js"></a>

Wenn ein GraphQL-Resolver aufgerufen wird, enthält er ein `context` Objekt, das relevante Informationen über die Anfrage enthält. Dazu gehören Argumente von einem Client, Identitätsinformationen sowie Daten aus dem übergeordneten GraphQL-Feld. Es speichert auch die Ergebnisse aus der Datenquelle, die im Antworthandler verwendet werden können. Weitere Informationen zu dieser Struktur und den verfügbaren Hilfsprogrammen, die beim Programmieren verwendet werden können, finden Sie in der [Resolver-Kontextobjektreferenz.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html)

*Beim Schreiben oder Bearbeiten einer Resolverfunktion können Sie ein Modell- oder *Testkontextobjekt* an den Konsoleneditor übergeben.* Auf diese Weise können Sie sehen, wie sowohl der Anforderungs- als auch der Antworthandler ausgewertet werden, ohne dass es tatsächlich mit einer Datenquelle zu tun hat. Beispiel: Sie können ein `firstname: Shaggy`-Testargument übergeben und sehen, wie es bei der Verwendung von `ctx.args.firstname` in Ihrem Vorlagencode ausgewertet wird. Sie können auch die Auswertung eines Dienstprogramm-Helferobjekts wie `util.autoId()` oder `util.time.nowISO8601()` testen.

### Resolver werden getestet
<a name="test-a-resolver-js"></a>

In diesem Beispiel werden Resolver mithilfe der AWS AppSync Konsole getestet.

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Funktionen.**

1. Wählen Sie eine bestehende Funktion aus.

1. Wählen Sie oben auf der Seite „**Funktion aktualisieren**“ die **Option Testkontext** auswählen und anschließend **Neuen Kontext erstellen** aus.

1. Wählen Sie ein Beispielkontextobjekt aus oder füllen Sie die JSON-Datei manuell im Fenster **Testkontext konfigurieren** unten aus.

1. Geben Sie einen **Namen für den Textkontext** ein.

1. Wählen Sie die Schaltfläche **Save (Speichern)** aus.

1. Wählen Sie **Run Test (Test ausführen)**, um den Resolver unter Verwendung dieses Mock-Kontexts auszuwerten.

Ein praktischeres Beispiel: Angenommen, Sie haben eine App, die einen GraphQL-Typ speichert`Dog`, die automatische ID-Generierung für Objekte verwendet und diese in Amazon DynamoDB speichert. Sie möchten auch einige Werte aus den Argumenten einer GraphQL-Mutation schreiben und nur bestimmten Benutzern ermöglichen, eine Antwort zu sehen. Der folgende Ausschnitt zeigt, wie das Schema aussehen könnte:

```
type Dog {
  breed: String
  color: String
}

type Mutation {
  addDog(firstname: String, age: Int): Dog
}
```

Sie können eine AWS AppSync Funktion schreiben und sie Ihrem `addDog` Resolver hinzufügen, um die Mutation zu behandeln. Um Ihre AWS AppSync Funktion zu testen, können Sie ein Kontextobjekt wie im folgenden Beispiel auffüllen. Nachstehend werden die Argumente `name` und `age` des Clients verwendet und ein `username` im `identity`-Objekt mit Daten gefüllt:

```
{
    "arguments" : {
        "firstname": "Shaggy",
        "age": 4
    },
    "source" : {},
    "result" : {
        "breed" : "Miniature Schnauzer",
        "color" : "black_grey"
    },
    "identity": {
        "sub" : "uuid",
        "issuer" : " https://cognito-idp.{region}.amazonaws.com/{userPoolId}",
        "username" : "Nadia",
        "claims" : { },
        "sourceIp" :[  "x.x.x.x" ],
        "defaultAuthStrategy" : "ALLOW"
    }
}
```

Sie können Ihre AWS AppSync Funktion mit dem folgenden Code testen:

```
import { util } from '@aws-appsync/utils';

export function request(ctx) {
  return {
    operation: 'PutItem',
    key: util.dynamodb.toMapValues({ id: util.autoId() }),
    attributeValues: util.dynamodb.toMapValues(ctx.args),
  };
}

export function response(ctx) {
  if (ctx.identity.username === 'Nadia') {
    console.log("This request is allowed")
    return ctx.result;
  }
  util.unauthorized();
}
```

Der ausgewertete Anforderungs- und Antworthandler enthält die Daten aus Ihrem Testkontextobjekt und den generierten Wert von`util.autoId()`. Wenn Sie `username` zu einem anderen Wert als `Nadia` ändern, werden die Ergebnisse nicht zurückgegeben, da die Autorisierungsprüfung fehlschlägt. Weitere Informationen zur detaillierten Zugriffskontrolle finden Sie unter [Anwendungsfälle für die Autorisierung](security-authorization-use-cases.md#aws-appsync-security-authorization-use-cases).

### Testen von Anforderungs- und Antworthandlern mit AWS AppSync APIs
<a name="testing-with-appsync-api-js"></a>

Sie können den `EvaluateCode` API-Befehl verwenden, um Ihren Code aus der Ferne mit simulierten Daten zu testen. Um mit dem Befehl zu beginnen, stellen Sie sicher, dass Sie die `appsync:evaluateMappingCode` Berechtigung zu Ihrer Richtlinie hinzugefügt haben. Beispiel:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "appsync:evaluateCode",
            "Resource": "arn:aws:appsync:us-east-1:111122223333:*"
        }
    ]
}
```

------

Sie können den Befehl nutzen, indem Sie das [AWS CLI](https://aws.amazon.com/cli/)oder verwenden [AWS SDKs](https://aws.amazon.com/tools/). Nehmen wir zum Beispiel das `Dog` Schema und seine AWS AppSync Funktionsanforderungs- und Antworthandler aus dem vorherigen Abschnitt. Speichern Sie den Code mithilfe der CLI auf Ihrer lokalen Station in einer Datei mit dem Namen `code.js` und speichern Sie das `context` Objekt anschließend in einer Datei mit dem Namen`context.json`. Führen Sie in Ihrer Shell den folgenden Befehl aus:

```
$ aws appsync evaluate-code \
  --code file://code.js \
  --function response \
  --context file://context.json \
  --runtime name=APPSYNC_JS,runtimeVersion=1.0.0
```

Die Antwort `evaluationResult` enthält eine, die die von Ihrem Handler zurückgegebene Nutzlast enthält. Es enthält auch ein `logs` Objekt, das die Liste der Protokolle enthält, die von Ihrem Handler während der Auswertung generiert wurden. Auf diese Weise können Sie Ihre Codeausführung einfach debuggen und Informationen zu Ihrer Evaluierung abrufen, um bei der Fehlerbehebung zu helfen. Beispiel:

```
{
    "evaluationResult": "{\"breed\":\"Miniature Schnauzer\",\"color\":\"black_grey\"}",
    "logs": [
        "INFO - code.js:13:5: \"This request is allowed\""
    ]
}
```

Das `evaluationResult` kann als JSON geparst werden, was Folgendes ergibt: 

```
{
  "breed": "Miniature Schnauzer",
  "color": "black_grey"
}
```

Mit dem SDK können Sie ganz einfach Tests aus Ihrer bevorzugten Testsuite integrieren, um das Verhalten Ihrer Handler zu überprüfen. Wir empfehlen, Tests mit dem [Jest Testing Framework](https://jestjs.io/) zu erstellen, aber jede Testsuite funktioniert. Der folgende Ausschnitt zeigt einen hypothetischen Validierungslauf. Beachten Sie, dass wir davon ausgehen, dass es sich bei der Bewertungsantwort um ein gültiges JSON handelt. Daher verwenden wir diese Methode, `JSON.parse` um JSON aus der Zeichenkettenantwort abzurufen:

```
const AWS = require('aws-sdk')
const fs = require('fs')
const client = new AWS.AppSync({ region: 'us-east-2' })
const runtime = {name:'APPSYNC_JS',runtimeVersion:'1.0.0')

test('request correctly calls DynamoDB', async () => {
  const code = fs.readFileSync('./code.js', 'utf8')
  const context = fs.readFileSync('./context.json', 'utf8')
  const contextJSON = JSON.parse(context)
  
  const response = await client.evaluateCode({ code, context, runtime, function: 'request' }).promise()
  const result = JSON.parse(response.evaluationResult)
  
  expect(result.key.id.S).toBeDefined()
  expect(result.attributeValues.firstname.S).toEqual(contextJSON.arguments.firstname)
})
```

 Dies führt zu dem folgenden Ergebnis:

```
Ran all test suites.
> jest

PASS ./index.test.js
✓ request correctly calls DynamoDB (543 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 totalTime: 1.511 s, estimated 2 s
```

## Debuggen einer Live-Abfrage
<a name="debugging-a-live-query-js"></a>

Es gibt keinen Ersatz für einen end-to-end Test und eine Protokollierung, um eine Produktionsanwendung zu debuggen. AWS AppSync ermöglicht es Ihnen, Fehler und vollständige Anfragedetails über Amazon zu protokollieren CloudWatch. Darüber hinaus können Sie die AWS AppSync Konsole verwenden, um GraphQL-Abfragen, -Mutationen und -Abonnements zu testen und Protokolldaten für jede Anfrage live zurück in den Abfrage-Editor zu streamen, um sie in Echtzeit zu debuggen. Für Abonnements zeigen die Protokolle Verbindungszeitinformationen an.

Um dies durchzuführen, müssen Sie Amazon CloudWatch Logs im Voraus aktiviert haben, wie unter [Überwachung und Protokollierung](monitoring.md#aws-appsync-monitoring) beschrieben. Wählen Sie als Nächstes in der AWS AppSync Konsole die Registerkarte **Abfragen** und geben Sie dann eine gültige GraphQL-Abfrage ein. Klicken Sie im unteren rechten Bereich auf das **Protokollfenster und ziehen Sie es, um die Protokollansicht** zu öffnen. Wählen Sie oben auf der Seite das Wiedergabe-Pfeilsymbol, um die GraphQL-Abfrage auszuführen. In wenigen Augenblicken werden Ihre vollständigen Anfrage- und Antwortprotokolle für den Vorgang in diesen Bereich gestreamt und Sie können sie in der Konsole einsehen.

# Konfiguration und Verwendung von Pipeline-Resolvern in AWS AppSync () JavaScript
<a name="pipeline-resolvers-js"></a>

AWS AppSync führt Resolver auf einem GraphQL-Feld aus. In einigen Fällen müssen Anwendungen mehrere Operationen ausführen, um ein einziges GraphQL-Feld aufzulösen. Mit Pipeline-Resolvern können Entwickler jetzt Operationen, sogenannte Funktionen, zusammenstellen und sie nacheinander ausführen. Pipeline-Resolver sind nützlich für Anwendungen, die z. B. eine Autorisierungsprüfung ausführen müssen, bevor sie Daten für ein Feld abrufen.

Weitere Informationen zur Architektur eines JavaScript Pipeline-Resolvers finden Sie in der Übersicht über die [JavaScriptResolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html#anatomy-of-a-pipeline-resolver-js).

## Schritt 1: Einen Pipeline-Resolver erstellen
<a name="create-a-pipeline-resolver-js"></a>

Gehen Sie in der AWS AppSync Konsole zur **Schemaseite**.

Speichern Sie das folgende Schema:

```
schema {
    query: Query
    mutation: Mutation
}

type Mutation {
    signUp(input: Signup): User
}

type Query {
    getUser(id: ID!): User
}

input Signup {
    username: String!
    email: String!
}

type User {
    id: ID!
    username: String
    email: AWSEmail
}
```

Wir werden einen Pipeline-Resolver an das **signUp**-Feld mit dem Typ der **Mutation** anhängen. Wählen Sie im Bereich **Mutationstyp** auf der rechten Seite neben dem `signUp` Mutationsfeld die Option **Anhängen** aus. Stellen Sie den Resolver auf `pipeline resolver` und die `APPSYNC_JS` Laufzeit ein und erstellen Sie dann den Resolver.

Unser Pipeline-Resolver meldet einen Benutzer an, indem er zuerst die eingegebene E-Mail-Adresse validiert und den Benutzer dann im System speichert. **Wir werden die E-Mail-Validierung in einer **ValidateEmail-Funktion** und das Speichern des Benutzers in einer SaveUser-Funktion kapseln.** Die **validateEmail**-Funktion wird zuerst ausgeführt, und, sofern die E-Mail gültig ist, anschließend die **saveUser**-Funktion.

Der Ausführungsablauf wird wie folgt aussehen:

1. Anforderungshandler für Mutation.SignUp Resolver

1. Funktion validateEmail

1. Funktion saveUser

1. Antworthandler für den Mutation.SignUp-Resolver

Da wir die Funktion **validateEmail** wahrscheinlich in anderen Resolvern auf unserer API wiederverwenden werden, möchten wir den Zugriff vermeiden, `ctx.args` da sich diese von einem GraphQL-Feld zum anderen ändern. Wir können stattdessen `ctx.stash` verwenden, um das E-Mail-Attribut aus dem Eingabefeldargument `signUp(input: Signup)` zu speichern.

Aktualisieren Sie Ihren Resolver-Code, indem Sie Ihre Anfrage- und Antwortfunktionen ersetzen:

```
export function request(ctx) {
    ctx.stash.email = ctx.args.input.email
    return {};
}

export function response(ctx) {
    return ctx.prev.result;
}
```

Wählen Sie **Erstellen** oder **Speichern**, um den Resolver zu aktualisieren.

## Schritt 2: Eine Funktion erstellen
<a name="create-a-function-js"></a>

Klicken Sie auf der Pipeline-Resolver-Seite im Abschnitt **Funktionen** auf **Funktion hinzufügen** und dann auf **Neue Funktion erstellen**. Es ist auch möglich, Funktionen zu erstellen, ohne die Resolver-Seite aufrufen zu müssen. Rufen Sie dazu in der AWS AppSync Konsole die Seite **Funktionen** auf. Wählen Sie die Schaltfläche **Create function** (Funktion erstellen). Wir erstellen eine Funktion, die prüft, ob eine E-Mail gültig ist und von einer bestimmten Domäne stammt. Sofern die E-Mail nicht gültig ist, löst die Funktion einen Fehler aus. Andernfalls leitet sie sämtliche Eingaben weiter.

Stellen Sie sicher, dass Sie eine Datenquelle vom Typ **NONE** erstellt haben. Wählen Sie diese Datenquelle in der Liste **Datenquellenname** aus. Geben Sie für den **Funktionsnamen** in ein`validateEmail`. Überschreiben Sie im **Funktionscode-Bereich** alles mit diesem Snippet:

```
import { util } from '@aws-appsync/utils';

export function request(ctx) {
  const { email } = ctx.stash;
  const valid = util.matches(
    '^[a-zA-Z0-9_.+-]+@(?:(?:[a-zA-Z0-9-]+\.)?[a-zA-Z]+\.)?(myvaliddomain)\.com',
    email
  );
  if (!valid) {
    util.error(`"${email}" is not a valid email.`);
  }

  return { payload: { email } };
}

export function response(ctx) {
  return ctx.result;
}
```

**Überprüfe deine Eingaben und wähle dann Erstellen.** Wir haben unsere **validateEmail**-Funktion erstellt. Wiederholen Sie diese Schritte, um die **SaveUser-Funktion** mit dem folgenden Code zu erstellen (Der Einfachheit halber verwenden wir eine **NONE-Datenquelle** und tun so, als ob der Benutzer nach der Ausführung der Funktion im System gespeichert wurde. ):

```
import { util } from '@aws-appsync/utils';

export function request(ctx) {
  return ctx.prev.result;
}

export function response(ctx) {
  ctx.result.id = util.autoId();
  return ctx.result;
}
```

Wir haben gerade unsere **SaveUser-Funktion** erstellt.

## Schritt 3: Hinzufügen einer Funktion zu einem Pipeline-Resolver
<a name="adding-a-function-to-a-pipeline-resolver-js"></a>

Unsere Funktionen hätten automatisch zu dem gerade erstellten Pipeline-Resolver hinzugefügt werden sollen. **Wenn dies nicht der Fall war oder Sie die Funktionen über die Funktionsseite erstellt haben, können Sie auf der `signUp` Resolver-Seite wieder auf **Funktion hinzufügen** klicken, um sie anzuhängen.** Fügen Sie dem Resolver sowohl die Funktionen **validateEmail** als auch **saveUser** hinzu. Die Funktion **validateEmail** muss vor der Funktion **saveUser** platziert werden. Wenn Sie weitere Funktionen hinzufügen, können Sie die Optionen „**Nach oben“ und „Nach** **unten“ verwenden,** um die Reihenfolge der Ausführung Ihrer Funktionen neu zu organisieren. Überprüfen Sie Ihre Änderungen und wählen Sie dann **Speichern**.

## Schritt 4: Eine Abfrage ausführen
<a name="running-a-query-js"></a>

Rufen Sie in der AWS AppSync Konsole die Seite **Abfragen** auf. Stellen Sie im Explorer sicher, dass Sie Ihre Mutation verwenden. Wenn nicht, wählen Sie `Mutation` in der Drop-down-Liste und dann`+`. Geben Sie die folgende Abfrage ein:

```
mutation {
  signUp(input: {email: "nadia@myvaliddomain.com", username: "nadia"}) {
    id
    username
  }
}
```

Dies sollte etwa Folgendes zurückgeben:

```
{
  "data": {
    "signUp": {
      "id": "256b6cc2-4694-46f4-a55e-8cb14cc5d7fc",
      "username": "nadia"
    }
  }
}
```

Wir haben mit einem Pipeline-Resolver unseren Benutzer erfolgreich angemeldet und die eingegebene E-Mail validiert.

# Basisabfragen erstellen (VTL)
<a name="configuring-resolvers"></a>

**Anmerkung**  
Wir unterstützen jetzt hauptsächlich die APPSYNC\$1JS-Laufzeit und ihre Dokumentation. [Bitte erwägen Sie, die APPSYNC\$1JS-Laufzeit und ihre Anleitungen hier zu verwenden.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)

GraphQL-Resolver verbinden die Felder in einem Schema mit einer Datenquelle. Resolver sind der Mechanismus, mit dem Anfragen erfüllt werden. AWS AppSync kann Resolver automatisch aus einem Schema erstellen und verbinden oder ein Schema erstellen und Resolver aus einer vorhandenen Tabelle verbinden, ohne dass Sie Code schreiben müssen.

Resolver, die AWS AppSync verwendet werden JavaScript , um einen GraphQL-Ausdruck in ein Format zu konvertieren, das die Datenquelle verwenden kann. Alternativ können Mapping-Vorlagen in [Apache Velocity Template Language (VTL)](https://velocity.apache.org/engine/2.0/vtl-reference.html) geschrieben werden, um einen GraphQL-Ausdruck in ein Format zu konvertieren, das die Datenquelle verwenden kann.

In diesem Abschnitt erfahren Sie, wie Sie Resolver mithilfe von VTL konfigurieren. [Eine einführende Programmieranleitung im Stil eines Tutorials zum Schreiben von Resolvern finden Sie im Programmierhandbuch für [Resolver-Mapping-Vorlagen. Hilfsprogramme, die Sie beim Programmieren](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide) verwenden können, finden Sie in der Kontextreferenz für Resolver-Mapping-Vorlagen.](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference) AWS AppSync verfügt außerdem über integrierte Test- und Debug-Workflows, die Sie verwenden können, wenn Sie von Grund auf neu bearbeiten oder Inhalte erstellen. Weitere Informationen finden Sie unter Resolver [testen und debuggen](test-debug-resolvers.md#aws-appsync-test-debug-resolvers).

Wir empfehlen, diese Anleitung zu befolgen, bevor Sie versuchen, eines der oben genannten Tutorials zu verwenden.

In diesem Abschnitt erfahren Sie, wie Sie einen Resolver erstellen, einen Resolver für Mutationen hinzufügen und erweiterte Konfigurationen verwenden.

## Erstellen Sie Ihren ersten Resolver
<a name="create-your-first-resolver"></a>

In Anlehnung an die Beispiele aus den vorherigen Abschnitten besteht der erste Schritt darin, einen Resolver für Ihren `Query` Typ zu erstellen.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. **Auf der rechten Seite der Seite befindet sich ein Fenster namens Resolvers.** Dieses Feld enthält eine Liste der Typen und Felder, wie sie in Ihrem **Schemafenster** auf der linken Seite der Seite definiert sind. Sie können Resolver an Felder anhängen. Wählen Sie beispielsweise unter dem **Abfragetyp** neben dem `getTodos` Feld die Option **Anhängen** aus.

1. Wählen Sie auf der Seite „**Resolver erstellen**“ die Datenquelle aus, die Sie im Handbuch [Datenquellen anhängen](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) erstellt haben. Im Fenster **Zuordnungsvorlagen konfigurieren** können Sie mithilfe der Dropdownliste auf der rechten Seite sowohl die generischen Vorlagen für die Anfrage als auch die Vorlage für die Antwortzuordnung auswählen oder Ihre eigenen erstellen.
**Anmerkung**  
Die Kopplung einer Vorlage für die Zuordnung von Anfragen mit einer Vorlage für die Zuordnung von Antworten wird als Unit-Resolver bezeichnet. Unit-Resolver sind in der Regel für Routineoperationen vorgesehen. Wir empfehlen, sie nur für einzelne Operationen mit einer kleinen Anzahl von Datenquellen zu verwenden. Für komplexere Operationen empfehlen wir die Verwendung von Pipeline-Resolvern, die mehrere Operationen mit mehreren Datenquellen nacheinander ausführen können.  
Weitere Informationen zum Unterschied zwischen Vorlagen für die Zuordnung von Anfragen und Antworten finden Sie unter [Unit-Resolver](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-mapping-template-reference-overview.html#unit-resolvers).  
Weitere Informationen zur Verwendung von Pipeline-Resolvern finden Sie unter [Pipeline-Resolver](pipeline-resolvers.md#aws-appsync-pipeline-resolvers).

1. Für allgemeine Anwendungsfälle verfügt die AWS AppSync Konsole über integrierte Vorlagen, mit denen Sie Elemente aus Datenquellen abrufen können (z. B. Abfragen aller Elemente, einzelne Suchvorgänge usw.). In der einfachen Version des Schemas aus [Designing your schema](designing-your-schema.md#aws-appsync-designing-your-schema), in der `getTodos` es keine Paginierung gab, sieht die Vorlage für die Anforderungszuweisung zum Auflisten von Elementen beispielsweise wie folgt aus:

   ```
   {
       "version" : "2017-02-28",
       "operation" : "Scan"
   }
   ```

1. Sie benötigen immer eine Vorlage für die Antwortzuweisung, die der Anfrage beiliegt. Die Konsole stellt eine Standardvorlage mit dem folgenden Pass-Through-Wert für Listen bereit:

   ```
   $util.toJson($ctx.result.items)
   ```

   In diesem Beispiel hat das `context`-Objekt (mit dem Alias `$ctx`) für Listen mit Elementen die Form `$context.result.items`. Wenn die GraphQL-Operation ein einzelnes Element zurückgibt, würde es sich um `$context.result` handeln. AWS AppSync stellt Hilfsfunktionen für allgemeine Operationen bereit, z. B. die oben aufgelistete Funktion `$util.toJson`, mit denen die Antworten richtig formatiert werden können. Eine vollständige Liste der Funktionen finden Sie unter [Referenz zum Resolver Mapping Template Utility.](resolver-util-reference.md#aws-appsync-resolver-mapping-template-util-reference)

1. Wählen Sie „**Resolver speichern**“.

------
#### [ API ]

1. Erstellen Sie ein Resolver-Objekt, indem Sie die [https://docs.aws.amazon.com/appsync/latest/APIReference/API_CreateResolver.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_CreateResolver.html)API aufrufen.

1. Sie können die Felder Ihres Resolvers ändern, indem Sie die [https://docs.aws.amazon.com/appsync/latest/APIReference/API_UpdateResolver.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_UpdateResolver.html)API aufrufen.

------
#### [ CLI ]

1. Erstellen Sie einen Resolver, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)Befehl ausführen.

   Für diesen speziellen Befehl müssen Sie 6 Parameter eingeben:

   1. Die `api-id` Ihrer API.

   1. Der `type-name` Typ, den Sie in Ihrem Schema ändern möchten. Im Konsolenbeispiel war das`Query`.

   1. Das `field-name` Feld, das Sie in Ihrem Typ ändern möchten. Im Konsolenbeispiel war das`getTodos`.

   1. Die `data-source-name` der Datenquelle, die Sie im Handbuch [Datenquellen anhängen](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) erstellt haben.

   1. Der`request-mapping-template`, welcher der Hauptteil der Anfrage ist. Im Konsolenbeispiel lautete das:

      ```
      {
          "version" : "2017-02-28",
          "operation" : "Scan"
      }
      ```

   1. Das`response-mapping-template`, was der Hauptteil der Antwort ist. Im Konsolenbeispiel lautete das:

      ```
      $util.toJson($ctx.result.items)
      ```

   Ein Beispielbefehl könnte so aussehen:

   ```
   aws appsync create-resolver --api-id abcdefghijklmnopqrstuvwxyz --type-name Query --field-name getTodos --data-source-name TodoTable --request-mapping-template "{ "version" : "2017-02-28", "operation" : "Scan", }" --response-mapping-template ""$"util.toJson("$"ctx.result.items)"
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "resolver": {
           "kind": "UNIT",
           "dataSourceName": "TodoTable",
           "requestMappingTemplate": "{ version : 2017-02-28, operation : Scan, }",
           "resolverArn": "arn:aws:appsync:us-west-2:107289374856:apis/abcdefghijklmnopqrstuvwxyz/types/Query/resolvers/getTodos",
           "typeName": "Query",
           "fieldName": "getTodos",
           "responseMappingTemplate": "$util.toJson($ctx.result.items)"
       }
   }
   ```

1. Führen Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-resolver.html)Befehl aus, um die Vorlagen für die and/or Feldzuweisung eines Resolvers zu ändern.

   Mit Ausnahme des `api-id` Parameters werden die im `create-resolver` Befehl verwendeten Parameter durch die neuen Werte aus dem `update-resolver` Befehl überschrieben.

------

## Einen Resolver für Mutationen hinzufügen
<a name="adding-a-resolver-for-mutations"></a>

Der nächste Schritt besteht darin, einen Resolver für Ihren `Mutation` Typ zu erstellen.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. Wählen Sie unter dem **Mutationstyp** neben dem `addTodo` Feld die Option **Anhängen** aus.

1. Wählen Sie auf der Seite „**Resolver erstellen**“ die Datenquelle aus, die Sie im Handbuch [Datenquellen anhängen](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) erstellt haben.

1. Im Fenster **Zuordnungsvorlagen konfigurieren** müssen Sie die Anforderungsvorlage ändern, da es sich um eine Mutation handelt, bei der Sie DynamoDB ein neues Element hinzufügen. Verwenden Sie die folgende Abfrage-Zuweisungsvorlage:

   ```
   {
       "version" : "2017-02-28",
       "operation" : "PutItem",
       "key" : {
           "id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
       },
       "attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
   }
   ```

1. AWS AppSync konvertiert automatisch die im `addTodo` Feld definierten Argumente aus Ihrem GraphQL-Schema in DynamoDB-Operationen. Im vorherigen Beispiel werden Datensätze in DynamoDB mit dem Schlüssel von gespeichert`id`, der vom Mutationsargument as übergeben wird. `$ctx.args.id` Alle anderen Felder, die Sie durchlaufen, werden automatisch DynamoDB-Attributen mit zugeordnet. `$util.dynamodb.toMapValuesJson($ctx.args)`

   Verwenden Sie für diesen Resolver die folgende Antwortzuweisungsvorlage:

   ```
   $util.toJson($ctx.result)
   ```

   AWS AppSync unterstützt auch Test- und Debug-Workflows für die Bearbeitung von Resolvern. Sie können ein `context`-Mock-Objekt verwenden, um den transformierten Wert der Vorlage vor dem Aufrufen anzuzeigen. Optional können Sie die vollständige Anforderungsausführung für eine Datenquelle interaktiv anzeigen, während Sie eine Abfrage ausführen. [Weitere Informationen finden Sie unter [Resolver testen und debuggen und Überwachen und Protokollieren](test-debug-resolvers.md#aws-appsync-test-debug-resolvers).](monitoring.md#aws-appsync-monitoring)

1. Wählen Sie „Resolver **speichern**“.

------
#### [ API ]

Sie können dies auch tun, APIs indem Sie die Befehle im Abschnitt [Erstellen Sie Ihren ersten Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) und die Parameterdetails aus diesem Abschnitt verwenden.

------
#### [ CLI ]

Sie können dies auch in der CLI tun, indem Sie die Befehle im Abschnitt [Create your first resolver](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) und die Parameterdetails aus diesem Abschnitt verwenden.

------

Wenn Sie die erweiterten Resolver nicht verwenden, können Sie zu diesem Zeitpunkt mit der Verwendung Ihrer GraphQL-API beginnen, wie [unter Verwenden Ihrer](using-your-api.md#aws-appsync-using-your-api) API beschrieben.

## Fortgeschrittene Resolver
<a name="advanced-resolvers"></a>

Wenn Sie dem Abschnitt „Erweitert“ folgen und unter [Entwerfen Ihres Schemas](designing-your-schema.md#aws-appsync-designing-your-schema) für einen paginierten Scan ein Beispielschema erstellen, verwenden Sie stattdessen die folgende Anforderungsvorlage für das `getTodos` Feld:

```
{
    "version" : "2017-02-28",
    "operation" : "Scan",
    "limit": $util.defaultIfNull(${ctx.args.limit}, 20),
    "nextToken": $util.toJson($util.defaultIfNullOrBlank($ctx.args.nextToken, null))
}
```

In diesem Paginierungsanwendungsfall ist die Antwortzuweisung mehr als nur ein Pass-Through, da sie sowohl den *Cursor* (damit der Kunde weiß, mit welcher Seite das nächste Mal begonnen wird) als auch den Ergebnissatz enthält. Die Zuweisungsvorlage sieht folgendermaßen aus:

```
{
    "todos": $util.toJson($context.result.items),
    "nextToken": $util.toJson($context.result.nextToken)
}
```

Die Felder in der vorherigen Antwortzuweisungsvorlage sollten mit den in Ihrem `TodoConnection`-Typ definierten Feldern übereinstimmen.

Für Beziehungen, bei denen Sie eine `Comments` Tabelle haben und das Kommentarfeld für den Typ auflösen (was den `Todo` Typ von zurückgibt`[Comment]`), können Sie eine Zuordnungsvorlage verwenden, die eine Abfrage für die zweite Tabelle ausführt. Dazu müssen Sie bereits eine Datenquelle für die `Comments` Tabelle erstellt haben, wie unter Hinzufügen [einer Datenquelle](attaching-a-data-source.md#aws-appsync-getting-started-build-a-schema-from-scratch) beschrieben.

**Anmerkung**  
Wir verwenden einen Abfragevorgang für eine zweite Tabelle nur zur Veranschaulichung. Sie könnten stattdessen eine andere Operation gegen DynamoDB verwenden. Darüber hinaus könnten Sie die Daten aus einer anderen Datenquelle abrufen, z. B. AWS Lambda aus Amazon OpenSearch Service, da die Beziehung durch Ihr GraphQL-Schema gesteuert wird.

------
#### [ Console ]

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. Wählen Sie unter dem Typ **Todo** neben dem Feld die `comments` Option **Anhängen** aus.

1. Wählen Sie auf der Seite „**Resolver erstellen**“ die Datenquelle für die Tabelle „**Kommentare**“ aus. Der Standardname für die Tabelle **Kommentare** aus den Schnellstartanleitungen lautet`AppSyncCommentTable`, er kann jedoch variieren, je nachdem, welchen Namen Sie der Tabelle gegeben haben.

1. Fügen Sie Ihrer Vorlage für die Anforderungszuweisung den folgenden Ausschnitt hinzu:

   ```
   {
       "version": "2017-02-28",
       "operation": "Query",
       "index": "todoid-index",
       "query": {
           "expression": "todoid = :todoid",
           "expressionValues": {
               ":todoid": {
                   "S": $util.toJson($context.source.id)
               }
           }
       }
   }
   ```

1. `context.source` verweist auf das übergeordnete Objekt des aktuellen Felds, das aufgelöst wird. In diesem Beispiel verweist `source.id` auf das `Todo`-Objekt, das dann für den Abfrageausdruck verwendet wird.

   Sie können die Pass-Through-Antwortzuweisungsvorlage folgendermaßen verwenden:

   ```
   $util.toJson($ctx.result.items)
   ```

1. Wählen Sie „Resolver **speichern**“.

1. Gehen Sie abschließend zurück zur **Schemaseite** in der Konsole, fügen Sie dem `addComment` Feld einen Resolver hinzu und geben Sie die Datenquelle für die `Comments` Tabelle an. Die Anforderungszuweisungsvorlage ist in diesem Fall eine einfache `PutItem`-Anweisung mit der spezifischen `todoid`, die als Argument kommentiert ist, aber Sie verwenden das Dienstprogramm `$utils.autoId()` zum Erstellen eines eindeutigen Sortierschlüssels für den Kommentar:

   ```
   {
       "version": "2017-02-28",
       "operation": "PutItem",
       "key": {
           "todoid": { "S": $util.toJson($context.arguments.todoid) },
           "commentid": { "S": "$util.autoId()" }
       },
       "attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
   }
   ```

   Verwenden Sie folgendermaßen eine Pass-Through-Antwortvorlage:

   ```
   $util.toJson($ctx.result)
   ```

------
#### [ API ]

Sie können dies auch tun, APIs indem Sie die Befehle im Abschnitt [Erstellen Sie Ihren ersten Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) und die Parameterdetails in diesem Abschnitt verwenden.

------
#### [ CLI ]

Sie können dies auch in der CLI tun, indem Sie die Befehle im Abschnitt [Create your first resolver](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html#create-your-first-resolver) und die Parameterdetails aus diesem Abschnitt verwenden.

------

# Deaktivieren von VTL-Mapping-Vorlagen mit direkten Lambda-Resolvern (VTL)
<a name="direct-lambda-reference"></a>

**Anmerkung**  
Wir unterstützen jetzt hauptsächlich die APPSYNC\$1JS-Laufzeit und ihre Dokumentation. [Bitte erwägen Sie, die APPSYNC\$1JS-Laufzeit und ihre Anleitungen hier zu verwenden.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)

Mit direkten Lambda-Resolvern können Sie die Verwendung von VTL-Mapping-Vorlagen bei der Verwendung von Datenquellen umgehen. AWS Lambda AWS AppSync kann eine Standardnutzlast für Ihre Lambda-Funktion sowie eine Standardübersetzung aus der Antwort einer Lambda-Funktion auf einen GraphQL-Typ bereitstellen. Sie können wählen, ob Sie eine Anforderungsvorlage, eine Antwortvorlage oder beides bereitstellen möchten, und AWS AppSync werden diese entsprechend behandeln. 

Weitere Informationen über die standardmäßige Anforderungsnutzlast und die damit AWS AppSync verbundene Antwortübersetzung finden Sie in der [Direct Lambda Resolver-Referenz](resolver-mapping-template-reference-lambda.md#direct-lambda-resolvers). Weitere Informationen zum Einrichten einer AWS Lambda Datenquelle und zum Einrichten einer IAM-Vertrauensrichtlinie finden Sie unter Eine Datenquelle [anhängen](attaching-a-data-source.md). 

## Direkte Lambda-Resolver konfigurieren
<a name="direct-lambda-reference-resolvers"></a>

In den folgenden Abschnitten erfahren Sie, wie Sie Lambda-Datenquellen anhängen und Lambda-Resolver zu Ihren Feldern hinzufügen.

### Fügen Sie eine Lambda-Datenquelle hinzu
<a name="direct-lambda-datasource"></a>

Bevor Sie direkte Lambda-Resolver aktivieren können, müssen Sie eine Lambda-Datenquelle hinzufügen.

------
#### [ Console ]

1. [Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole. AppSync](https://console.aws.amazon.com/appsync/)

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. Wählen Sie in der **Seitenleiste** **Datenquellen** aus.

1. Klicken Sie auf **Create data source**.

   1. Geben Sie **unter Datenquellenname** einen Namen für Ihre Datenquelle ein, z. B. **myFunction** 

   1. Wählen Sie als **Datenquellentyp** die Option **AWS Lambda Funktion** aus.

   1. Wählen Sie für **Region** die entsprechende Region aus.

   1. Wählen Sie für **Function ARN** die Lambda-Funktion aus der Dropdownliste aus. Sie können nach dem Funktionsnamen suchen oder den ARN der Funktion, die Sie verwenden möchten, manuell eingeben. 

   1. Erstellen Sie eine neue IAM-Rolle (empfohlen) oder wählen Sie eine vorhandene Rolle aus, die über die `lambda:invokeFunction` IAM-Berechtigung verfügt. Für bestehende Rollen ist eine Vertrauensrichtlinie erforderlich, wie im Abschnitt [Eine Datenquelle anhängen](attaching-a-data-source.md) beschrieben. 

      Im Folgenden finden Sie ein Beispiel für eine IAM-Richtlinie, die über die erforderlichen Berechtigungen für die Ausführung von Vorgängen auf der Ressource verfügt:

------
#### [ JSON ]

****  

      ```
      { 
           "Version":"2012-10-17",		 	 	  
           "Statement": [ 
               { 
                   "Effect": "Allow", 
                   "Action": [ "lambda:invokeFunction" ], 
                   "Resource": [ 
                       "arn:aws:lambda:us-west-2:123456789012:function:myFunction", 
                       "arn:aws:lambda:us-west-2:123456789012:function:myFunction:*" 
                   ] 
               } 
           ] 
       }
      ```

------

1. Wählen Sie die Schaltfläche **Erstellen** aus.

------
#### [ CLI ]

1. Erstellen Sie ein Datenquellenobjekt, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-data-source.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-data-source.html)Befehl ausführen.

   Für diesen speziellen Befehl müssen Sie 4 Parameter eingeben:

   1. Die `api-id` Ihrer API.

   1. Die `name` Ihrer Datenquelle. Im Konsolenbeispiel ist dies der **Name der Datenquelle**.

   1. Der `type` Wert der Datenquelle. Im Konsolenbeispiel ist dies eine **AWS Lambda Funktion**.

   1. Das`lambda-config`, was die **Funktion ARN** im Konsolenbeispiel ist.
**Anmerkung**  
Es gibt andere Parameter wie diesen`Region`, die konfiguriert werden müssen, aber normalerweise werden sie standardmäßig auf Ihre CLI-Konfigurationswerte gesetzt.

   Ein Beispielbefehl könnte wie folgt aussehen:

   ```
   aws appsync create-data-source --api-id abcdefghijklmnopqrstuvwxyz --name myFunction --type AWS_LAMBDA --lambda-config lambdaFunctionArn=arn:aws:lambda:us-west-2:102847592837:function:appsync-lambda-example
   ```

   Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

   ```
   {
       "dataSource": {
           "dataSourceArn": "arn:aws:appsync:us-west-2:102847592837:apis/abcdefghijklmnopqrstuvwxyz/datasources/myFunction",
           "type": "AWS_LAMBDA",
           "name": "myFunction",
           "lambdaConfig": {
               "lambdaFunctionArn": "arn:aws:lambda:us-west-2:102847592837:function:appsync-lambda-example"
           }
       }
   }
   ```

1. Führen Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-data-source.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-data-source.html)Befehl aus, um die Attribute einer Datenquelle zu ändern.

   Mit Ausnahme des `api-id` Parameters werden die im `create-data-source` Befehl verwendeten Parameter durch die neuen Werte aus dem `update-data-source` Befehl überschrieben.

------

### Direkte Lambda-Resolver aktivieren
<a name="direct-lambda-enable-templates"></a>

Nachdem Sie eine Lambda-Datenquelle erstellt und die entsprechende IAM-Rolle eingerichtet haben, um den Aufruf der Funktion AWS AppSync zu ermöglichen, können Sie sie mit einer Resolver- oder Pipeline-Funktion verknüpfen. 

------
#### [ Console ]

1. [Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole. AppSync](https://console.aws.amazon.com/appsync/)

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. Wählen Sie im **Resolver-Fenster** ein Feld oder eine Operation aus und klicken Sie dann auf die Schaltfläche „**Anhängen**“.

1. Wählen Sie auf der Seite **Neuen Resolver erstellen** die Lambda-Funktion aus der Dropdownliste aus.

1. Um direkte Lambda-Resolver zu nutzen, stellen Sie sicher, dass Vorlagen für die Anfrage- und Antwortzuordnung im Abschnitt **Zuordnungsvorlagen konfigurieren** deaktiviert sind.

1. Wählen Sie die Schaltfläche „**Resolver speichern**“.

------
#### [ CLI ]
+ Erstellen Sie einen Resolver, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/create-resolver.html)Befehl ausführen.

  Für diesen speziellen Befehl müssen Sie 6 Parameter eingeben:

  1. Die `api-id` Ihrer API.

  1. Der `type-name` Typ in Ihrem Schema.

  1. Der `field-name` des Felds in Ihrem Schema.

  1. Der `data-source-name` oder der Name Ihrer Lambda-Funktion.

  1. Der`request-mapping-template`, welcher der Hauptteil der Anfrage ist. Im Konsolenbeispiel wurde dies deaktiviert:

     ```
     " "
     ```

  1. Das`response-mapping-template`, was der Hauptteil der Antwort ist. Im Konsolenbeispiel wurde dies ebenfalls deaktiviert:

     ```
     " "
     ```

  Ein Beispielbefehl könnte so aussehen:

  ```
  aws appsync create-resolver --api-id abcdefghijklmnopqrstuvwxyz --type-name Subscription --field-name onCreateTodo --data-source-name LambdaTest --request-mapping-template " " --response-mapping-template " "
  ```

  Eine Ausgabe wird in der CLI zurückgegeben. Hier ein Beispiel:

  ```
  {
      "resolver": {
          "resolverArn": "arn:aws:appsync:us-west-2:102847592837:apis/abcdefghijklmnopqrstuvwxyz/types/Subscription/resolvers/onCreateTodo",
          "typeName": "Subscription",
          "kind": "UNIT",
          "fieldName": "onCreateTodo",
          "dataSourceName": "LambdaTest"
      }
  }
  ```

------

Wenn Sie Ihre Mapping-Vorlagen deaktivieren, treten mehrere zusätzliche Verhaltensweisen auf in AWS AppSync:
+ Indem Sie eine Zuordnungsvorlage deaktivieren, signalisieren Sie, AWS AppSync dass Sie die in der [Direct Lambda-Resolver-Referenz](resolver-mapping-template-reference-lambda.md#direct-lambda-resolvers) angegebenen Standarddatenübersetzungen akzeptieren.
+ [Wenn Sie die Vorlage für die Anforderungszuweisung deaktivieren, erhält Ihre Lambda-Datenquelle eine Nutzlast, die aus dem gesamten Context-Objekt besteht.](resolver-context-reference.md)
+ Wenn Sie die Antwortzuordnungsvorlage deaktivieren, wird das Ergebnis Ihres Lambda-Aufrufs je nach Version der Anforderungszuordnungsvorlage übersetzt oder ob die Anforderungszuordnungsvorlage ebenfalls deaktiviert ist. 

# Resolver in AWS AppSync (VTL) testen und debuggen
<a name="test-debug-resolvers"></a>

**Anmerkung**  
Wir unterstützen jetzt hauptsächlich die APPSYNC\$1JS-Laufzeit und ihre Dokumentation. [Bitte erwägen Sie, die APPSYNC\$1JS-Laufzeit und ihre Anleitungen hier zu verwenden.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)

AWS AppSync führt Resolver in einem GraphQL-Feld gegen eine Datenquelle aus. Wie in der [Übersicht über Resolver-Mapping-Vorlagen beschrieben, kommunizieren Resolver](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview) mithilfe einer Vorlagensprache mit Datenquellen. Auf diese Weise können Sie das Verhalten anpassen und Logik und Bedingungen vor und nach der Kommunikation mit der Datenquelle anwenden. Eine einführende Programmieranleitung im Stil eines Tutorials zum Schreiben von Resolvern finden Sie im Programmierleitfaden für [Resolver-Mapping-Vorlagen](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide).

Um Entwicklern beim Schreiben, Testen und Debuggen dieser Resolver zu helfen, bietet die AWS AppSync Konsole auch Tools zum Erstellen einer GraphQL-Anfrage und -Antwort mit Scheindaten bis hin zum einzelnen Field-Resolver. Darüber hinaus können Sie Abfragen, Mutationen und Abonnements in der AWS AppSync Konsole durchführen und einen detaillierten Protokollstream der gesamten Anfrage CloudWatch von Amazon einsehen. Dieser umfasst die Ergebnisse aus einer Datenquelle.

## Testen mit Scheindaten
<a name="testing-with-mock-data"></a>

Wenn ein GraphQL-Resolver aufgerufen wird, enthält er ein `context` Objekt, das Informationen über die Anfrage enthält. Dazu gehören Argumente von einem Client, Identitätsinformationen sowie Daten aus dem übergeordneten GraphQL-Feld. Es enthält auch die Ergebnisse aus der Datenquelle, die in der Antwortvorlage verwendet werden können. Weitere Informationen über diese Struktur und die verfügbaren Helferobjekt-Dienstprogramme finden Sie in der [Referenz zur Resolver-Zuweisungsvorlage "Context"](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference).

*Beim Schreiben oder Bearbeiten eines Resolvers können Sie ein Modell- oder *Testkontextobjekt* an den Konsoleneditor übergeben.* Auf diese Weise können Sie sehen, wie sowohl die Anforderungs- als auch die Antwortvorlage ausgewertet werden, ohne tatsächlich auf eine Datenquelle zuzugreifen. Beispiel: Sie können ein `firstname: Shaggy`-Testargument übergeben und sehen, wie es bei der Verwendung von `$ctx.args.firstname` in Ihrem Vorlagencode ausgewertet wird. Sie können auch die Auswertung eines Dienstprogramm-Helferobjekts wie `$util.autoId()` oder `util.time.nowISO8601()` testen.

### Resolver testen
<a name="test-a-resolver"></a>

In diesem Beispiel werden Resolver mithilfe der AWS AppSync Konsole getestet.

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.

   1. **Wählen Sie in der **Seitenleiste** Schema aus.**

1. Falls Sie dies noch nicht getan haben, wählen Sie unter dem Typ und neben dem Feld die Option **Anhängen** aus, um Ihren Resolver hinzuzufügen.

   [Weitere Informationen zum Erstellen eines vollständigen Resolvers finden Sie unter Resolver konfigurieren.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers.html)

   Wählen Sie andernfalls den Resolver aus, der sich bereits im Feld befindet.

1. Wählen Sie oben auf der Seite **Resolver bearbeiten** die **Option Testkontext auswählen und dann Neuen Kontext** **erstellen** aus.

1. Wählen Sie ein Beispielkontextobjekt aus oder füllen Sie die JSON-Datei manuell im Fenster mit dem **Ausführungskontext unten** aus.

1. Geben Sie einen **Namen für den Textkontext** ein.

1. Wählen Sie die Schaltfläche **Save (Speichern)** aus.

1. Wählen Sie oben auf der Seite **„Resolver bearbeiten**“ die Option **Test ausführen** aus.

Ein praktischeres Beispiel: Angenommen, Sie haben eine App, die einen GraphQL-Typ speichert`Dog`, die automatische ID-Generierung für Objekte verwendet und diese in Amazon DynamoDB speichert. Sie können außerdem einige Werte aus den Argumenten einer GraphQL-Mutation schreiben und nur bestimmten Benutzern das Anzeigen einer Antwort erlauben. Das Schema kann beispielsweise wie folgt aussehen:

```
type Dog {
  breed: String
  color: String
}

type Mutation {
  addDog(firstname: String, age: Int): Dog
}
```

Wenn Sie einen Resolver für die `addDog` Mutation hinzufügen, können Sie ein Kontextobjekt wie im folgenden Beispiel auffüllen. Nachstehend werden die Argumente `name` und `age` des Clients verwendet und ein `username` im `identity`-Objekt mit Daten gefüllt:

```
{
    "arguments" : {
        "firstname": "Shaggy",
        "age": 4
    },
    "source" : {},
    "result" : {
        "breed" : "Miniature Schnauzer",
        "color" : "black_grey"
    },
    "identity": {
        "sub" : "uuid",
        "issuer" : " https://cognito-idp.{region}.amazonaws.com/{userPoolId}",
        "username" : "Nadia",
        "claims" : { },
        "sourceIp" :[  "x.x.x.x" ],
        "defaultAuthStrategy" : "ALLOW"
    }
}
```

Sie können dies mithilfe der folgenden Anforderungs- und Antwortzuweisungsvorlagen testen:

 **Request Template** 

```
{
    "version" : "2017-02-28",
    "operation" : "PutItem",
    "key" : {
        "id" : { "S" : "$util.autoId()" }
    },
    "attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args)
}
```

 **Antwortvorlage** 

```
#if ($context.identity.username == "Nadia")
  $util.toJson($ctx.result)
#else
  $util.unauthorized()
#end
```

Die ausgewertete Vorlage enthält die Daten aus Ihrem Testkontextobjekt und den generierten Wert aus `$util.autoId()`. Wenn Sie `username` zu einem anderen Wert als `Nadia` ändern, werden die Ergebnisse nicht zurückgegeben, da die Autorisierungsprüfung fehlschlägt. Weitere Informationen zur detaillierten Zugriffskontrolle finden Sie unter Anwendungsfälle für die [Autorisierung](security-authorization-use-cases.md#aws-appsync-security-authorization-use-cases).

### Testen von Mapping-Vorlagen mit's AWS AppSync APIs
<a name="testing-with-appsync-api"></a>

Sie können den `EvaluateMappingTemplate` API-Befehl verwenden, um Ihre Mapping-Vorlagen mit simulierten Daten aus der Ferne zu testen. Um mit dem Befehl zu beginnen, stellen Sie sicher, dass Sie die `appsync:evaluateMappingTemplate` entsprechende Berechtigung zu Ihrer Richtlinie hinzugefügt haben. Beispiel:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "appsync:evaluateMappingTemplate",
            "Resource": "arn:aws:appsync:us-east-1:111122223333:*"
        }
    ]
}
```

------

Sie können den Befehl nutzen, indem Sie das [AWS CLI](https://aws.amazon.com/cli/)oder verwenden [AWS SDKs](https://aws.amazon.com/tools/). Nehmen Sie zum Beispiel das `Dog` Schema und die zugehörigen request/response Mapping-Vorlagen aus dem vorherigen Abschnitt. Speichern Sie die Anforderungsvorlage mithilfe der CLI auf Ihrer lokalen Station in einer Datei mit dem Namen `request.vtl` und speichern Sie das `context` Objekt anschließend in einer Datei mit dem Namen`context.json`. Führen Sie in Ihrer Shell den folgenden Befehl aus:

```
aws appsync evaluate-mapping-template --template file://request.vtl --context file://context.json
```

Dieser Befehl gibt die folgende Antwort zurück.

```
{
  "evaluationResult": "{\n    \"version\" : \"2017-02-28\",\n    \"operation\" : \"PutItem\",\n    \"key\" : {\n        \"id\" : { \"S\" : \"afcb4c85-49f8-40de-8f2b-248949176456\" }\n    },\n    \"attributeValues\" : {\"firstname\":{\"S\":\"Shaggy\"},\"age\":{\"N\":4}}\n}\n"
}
```

Das `evaluationResult` enthält die Ergebnisse des Testens Ihrer bereitgestellten Vorlage mit der bereitgestellten`context`. Sie können Ihre Vorlagen auch mit dem testen AWS SDKs. Hier ist ein Beispiel für die Verwendung des AWS SDK für JavaScript V2: 

```
const AWS = require('aws-sdk')
const client = new AWS.AppSync({ region: 'us-east-2' })

const template = fs.readFileSync('./request.vtl', 'utf8')
const context = fs.readFileSync('./context.json', 'utf8')

client
  .evaluateMappingTemplate({ template, context })
  .promise()
  .then((data) => console.log(data))
```

Mit dem SDK können Sie ganz einfach Tests aus Ihrer bevorzugten Testsuite integrieren, um das Verhalten Ihrer Vorlage zu überprüfen. Wir empfehlen, Tests mit dem [Jest Testing Framework](https://jestjs.io/) zu erstellen, aber jede Testsuite funktioniert. Der folgende Ausschnitt zeigt einen hypothetischen Validierungslauf. Beachten Sie, dass wir davon ausgehen, dass es sich bei der Bewertungsantwort um ein gültiges JSON handelt. Daher verwenden wir diese Methode, `JSON.parse` um JSON aus der Zeichenkettenantwort abzurufen:

```
const AWS = require('aws-sdk')
const fs = require('fs')
const client = new AWS.AppSync({ region: 'us-east-2' })

test('request correctly calls DynamoDB', async () => {
  const template = fs.readFileSync('./request.vtl', 'utf8')
  const context = fs.readFileSync('./context.json', 'utf8')
  const contextJSON = JSON.parse(context)
  
  const response = await client.evaluateMappingTemplate({ template, context }).promise()
  const result = JSON.parse(response.evaluationResult)
  
  expect(result.key.id.S).toBeDefined()
  expect(result.attributeValues.firstname.S).toEqual(contextJSON.arguments.firstname)
})
```

 Dies führt zu dem folgenden Ergebnis:

```
Ran all test suites.
> jest

PASS ./index.test.js
✓ request correctly calls DynamoDB (543 ms)

Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 1.511 s, estimated 2 s
```

## Debuggen einer Live-Abfrage
<a name="debugging-a-live-query"></a>

Es gibt keinen Ersatz für einen end-to-end Test und eine Protokollierung, um eine Produktionsanwendung zu debuggen. AWS AppSync ermöglicht es Ihnen, Fehler und vollständige Anfragedetails über Amazon zu protokollieren CloudWatch. Darüber hinaus können Sie die AWS AppSync Konsole verwenden, um GraphQL-Abfragen, -Mutationen und -Abonnements zu testen und Protokolldaten für jede Anfrage live zurück in den Abfrage-Editor zu streamen, um sie in Echtzeit zu debuggen. Für Abonnements zeigen die Protokolle Verbindungszeitinformationen an.

Um dies durchzuführen, müssen Sie Amazon CloudWatch Logs im Voraus aktiviert haben, wie unter [Überwachung und Protokollierung](monitoring.md#aws-appsync-monitoring) beschrieben. Wählen Sie als Nächstes in der AWS AppSync Konsole die Registerkarte **Abfragen** und geben Sie dann eine gültige GraphQL-Abfrage ein. Klicken Sie im unteren rechten Bereich auf das **Protokollfenster und ziehen Sie es, um die Protokollansicht** zu öffnen. Wählen Sie oben auf der Seite das Wiedergabe-Pfeilsymbol, um die GraphQL-Abfrage auszuführen. In wenigen Augenblicken werden die vollständigen Anforderungs- und Antwortprotokolle für die Operation an diesen Abschnitt der Konsole gestreamt und können angezeigt werden.

# Konfiguration und Verwendung von Pipeline-Resolvern in AWS AppSync (VTL)
<a name="pipeline-resolvers"></a>

**Anmerkung**  
Wir unterstützen jetzt hauptsächlich die APPSYNC\$1JS-Laufzeit und ihre Dokumentation. [Bitte erwägen Sie, die APPSYNC\$1JS-Laufzeit und ihre Anleitungen hier zu verwenden.](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)

AWS AppSync führt Resolver auf einem GraphQL-Feld aus. In einigen Fällen müssen Anwendungen mehrere Operationen ausführen, um ein einziges GraphQL-Feld aufzulösen. Mit Pipeline-Resolvern können Entwickler jetzt Operationen, sogenannte Funktionen, zusammenstellen und sie nacheinander ausführen. Pipeline-Resolver sind nützlich für Anwendungen, die z. B. eine Autorisierungsprüfung ausführen müssen, bevor sie Daten für ein Feld abrufen.

Ein Pipeline-Resolver besteht aus einer Zuweisungsvorlage für **Vorher**, einer Zuweisungsvorlage für **Nachher** und einer Liste von Funktionen. Jede Funktion verfügt über eine Vorlage für die Zuordnung von **Anfragen** und **Antworten**, die sie anhand einer Datenquelle ausführt. Da ein Pipeline-Resolver die Ausführung an eine Liste von Funktionen delegiert, ist er mit keiner Datenquelle verknüpft. Unit-Resolver und Funktionen sind Primitive, die Operationen an Datenquellen ausführen. Weitere Informationen finden Sie in der [Übersicht über die Resolver-Mapping-Vorlagen](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview).

## Schritt 1: Einen Pipeline-Resolver erstellen
<a name="create-a-pipeline-resolver"></a>

Rufen Sie in der AWS AppSync Konsole die **Schemaseite** auf.

Speichern Sie das folgende Schema:

```
schema {
    query: Query
    mutation: Mutation
}

type Mutation {
    signUp(input: Signup): User
}

type Query {
    getUser(id: ID!): User
}

input Signup {
    username: String!
    email: String!
}

type User {
    id: ID!
    username: String
    email: AWSEmail
}
```

Wir werden einen Pipeline-Resolver an das **signUp**-Feld mit dem Typ der **Mutation** anhängen. Wählen Sie im Bereich **Mutationstyp** auf der rechten Seite neben dem `signUp` Mutationsfeld die Option **Anhängen** aus. Klicken Sie auf der Seite „Resolver erstellen“ auf **Aktionen** und dann auf **Laufzeit aktualisieren**. Wählen Sie`Pipeline Resolver`, wählen Sie dann `VTL` und wählen Sie dann **Aktualisieren**. Die Seite sollte nun drei Abschnitte enthalten: einen Textbereich **Vor dem Zuordnen der Vorlage**, einen Abschnitt mit **Funktionen** und einen Textbereich **Nach dem Zuordnen der Vorlage**.

Unser Pipeline-Resolver meldet einen Benutzer an, indem er zuerst die eingegebene E-Mail-Adresse validiert und den Benutzer dann im System speichert. Wir kapseln die E-Mail-Validierung in einer **validateEmail**-Funktion und das Speichern des Benutzers in einer **saveUser**-Funktion. Die **validateEmail**-Funktion wird zuerst ausgeführt, und, sofern die E-Mail gültig ist, anschließend die **saveUser**-Funktion.

Der Ausführungsablauf sieht wie folgt aus:

1. Resolver-Zuweisungsvorlage für Anforderungen Mutation.signUp

1. Funktion validateEmail

1. Funktion saveUser

1. Resolver-Zuweisungsvorlage für Antworten Mutation.signUp

Da wir die Funktion **validateEmail** wahrscheinlich in anderen Resolvern auf unserer API wiederverwenden werden, möchten wir den Zugriff vermeiden, `$ctx.args` da sich diese von einem GraphQL-Feld zum anderen ändern. Wir können stattdessen `$ctx.stash` verwenden, um das E-Mail-Attribut aus dem Eingabefeldargument `signUp(input: Signup)` zu speichern.

**VOR der Zuordnungsvorlage:**

```
## store email input field into a generic email key
$util.qr($ctx.stash.put("email", $ctx.args.input.email))
{}
```

Die Konsole stellt eine standardmäßige **Passthrough-AFTER-Zuordnungsvorlage** bereit, die wir verwenden werden:

```
$util.toJson($ctx.result)
```

Wählen Sie **Erstellen** oder **Speichern**, um den Resolver zu aktualisieren.

## Schritt 2: Eine Funktion erstellen
<a name="create-a-function"></a>

Klicken Sie auf der Pipeline-Resolver-Seite im Abschnitt **Funktionen** auf **Funktion hinzufügen** und dann auf **Neue Funktion erstellen**. Es ist auch möglich, Funktionen zu erstellen, ohne die Resolver-Seite aufrufen zu müssen. Rufen Sie dazu in der AWS AppSync Konsole die Seite **Funktionen** auf. Wählen Sie die Schaltfläche **Create function** (Funktion erstellen). Wir erstellen eine Funktion, die prüft, ob eine E-Mail gültig ist und von einer bestimmten Domäne stammt. Sofern die E-Mail nicht gültig ist, löst die Funktion einen Fehler aus. Andernfalls leitet sie sämtliche Eingaben weiter.

Wählen Sie auf der Seite „Neue Funktionen“ die Option „**Aktionen**“ und dann „**Laufzeit aktualisieren**“. Wählen Sie „`VTL`**Aktualisieren**“. Stellen Sie sicher, dass Sie eine Datenquelle vom Typ **NONE** erstellt haben. Wählen Sie diese Datenquelle in der Liste **Datenquellenname** aus. Geben Sie für **den Funktionsnamen** in ein`validateEmail`. Überschreiben Sie im **Funktionscode-Bereich** alles mit diesem Snippet:

```
#set($valid = $util.matches("^[a-zA-Z0-9_.+-]+@(?:(?:[a-zA-Z0-9-]+\.)?[a-zA-Z]+\.)?(myvaliddomain)\.com", $ctx.stash.email))
#if (!$valid)
    $util.error("$ctx.stash.email is not a valid email.")
#end
{
    "payload": { "email": $util.toJson(${ctx.stash.email}) }
}
```

Fügen Sie dies in die Antwortzuordnungsvorlage ein:

```
$util.toJson($ctx.result)
```

Überprüfen Sie Ihre Änderungen und wählen Sie dann **Erstellen** aus. Wir haben unsere **validateEmail**-Funktion erstellt. Wiederholen Sie diese Schritte, um die **SaveUser-Funktion** mit den folgenden Anforderungs- und Antwortzuordnungsvorlagen zu erstellen (Der Einfachheit halber verwenden wir eine **NONE-Datenquelle** und tun so, als ob der Benutzer nach der Ausführung der Funktion im System gespeichert wurde. ): 

Zuweisungsvorlage für Anforderungen:

```
## $ctx.prev.result contains the signup input values. We could have also
## used $ctx.args.input.
{
    "payload": $util.toJson($ctx.prev.result)
}
```

Zuweisungsvorlage für Antworten:

```
## an id is required so let's add a unique random identifier to the output
$util.qr($ctx.result.put("id", $util.autoId()))
$util.toJson($ctx.result)
```

Wir haben gerade unsere **SaveUser-Funktion** erstellt.

## Schritt 3: Hinzufügen einer Funktion zu einem Pipeline-Resolver
<a name="adding-a-function-to-a-pipeline-resolver"></a>

Unsere Funktionen hätten automatisch zu dem Pipeline-Resolver hinzugefügt werden sollen, den wir gerade erstellt haben. **Wenn dies nicht der Fall war oder Sie die Funktionen über die Seite Funktionen erstellt haben, können Sie auf der Resolver-Seite auf **Funktion hinzufügen** klicken, um sie anzuhängen.** Fügen Sie dem Resolver sowohl die Funktionen **validateEmail** als auch **saveUser** hinzu. Die Funktion **validateEmail** muss vor der Funktion **saveUser** platziert werden. Wenn Sie weitere Funktionen hinzufügen, können Sie die Optionen „**Nach oben“ und „Nach** **unten“ verwenden,** um die Reihenfolge der Ausführung Ihrer Funktionen neu zu organisieren. Überprüfen Sie Ihre Änderungen und wählen Sie dann **Speichern**.

## Schritt 4: Eine Abfrage ausführen
<a name="executing-a-query"></a>

Rufen Sie in der AWS AppSync Konsole die Seite **Abfragen** auf. Stellen Sie im Explorer sicher, dass Sie Ihre Mutation verwenden. Wenn nicht, wählen Sie `Mutation` in der Drop-down-Liste und dann`+`. Geben Sie die folgende Abfrage ein:

```
mutation {
  signUp(input: {
    email: "nadia@myvaliddomain.com"
    username: "nadia"
  }) {
    id
    email
  }
}
```

Dies sollte etwa Folgendes zurückgeben:

```
{
  "data": {
    "signUp": {
      "id": "256b6cc2-4694-46f4-a55e-8cb14cc5d7fc",
      "email": "nadia@myvaliddomain.com"
    }
  }
}
```

Wir haben mit einem Pipeline-Resolver unseren Benutzer erfolgreich angemeldet und die eingegebene E-Mail validiert. Ein detailliertes Tutorial zu Pipeline-Resolvern finden Sie unter [Tutorial: Pipeline-Resolver](tutorial-pipeline-resolvers.md#aws-appsync-tutorial-pipeline-resolvers) 

# Eine AWS AppSync API mit dem AWS CDK verwenden
<a name="using-your-api"></a>

**Tipp**  
Bevor Sie das CDK verwenden, empfehlen wir, die [offizielle Dokumentation](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html) des CDK zusammen mit der [CDK-Referenz](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_appsync-readme.html) zu AWS AppSync lesen.  
Wir empfehlen außerdem sicherzustellen, dass Ihre [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) - und [NPM-Installationen](https://docs.npmjs.com/) auf Ihrem System funktionieren.

In diesem Abschnitt werden wir eine einfache CDK-Anwendung erstellen, die Elemente aus einer DynamoDB-Tabelle hinzufügen und aus ihr abrufen kann. [Dies ist als Schnellstartbeispiel gedacht, bei dem ein Teil des Codes aus den Abschnitten [Schema entwerfen](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html), [Datenquelle anhängen und Resolvers konfigurieren](https://docs.aws.amazon.com/appsync/latest/devguide/attaching-a-data-source.html) () verwendet wird. JavaScript](https://docs.aws.amazon.com/appsync/latest/devguide/configuring-resolvers-js.html)

## Ein CDK-Projekt einrichten
<a name="Setting-up-a-cdk-project"></a>

**Warnung**  
Diese Schritte sind je nach Umgebung möglicherweise nicht ganz korrekt. Wir gehen davon aus, dass auf Ihrem System die erforderlichen Dienstprogramme installiert sind, dass eine Verbindung zu AWS Diensten hergestellt werden kann und dass die richtigen Konfigurationen vorhanden sind.

Der erste Schritt ist die Installation des AWS CDK. In Ihrer CLI können Sie den folgenden Befehl eingeben:

```
npm install -g aws-cdk
```

Als Nächstes müssen Sie ein Projektverzeichnis erstellen und dann dorthin navigieren. Ein Beispiel für einen Befehlssatz zum Erstellen und Navigieren zu einem Verzeichnis ist:

```
mkdir example-cdk-app
cd example-cdk-app
```

Als Nächstes müssen Sie eine App erstellen. Unser Service verwendet hauptsächlich TypeScript. Geben Sie in Ihrem Projektverzeichnis den folgenden Befehl ein:

```
cdk init app --language typescript
```

Wenn Sie dies tun, wird eine CDK-App zusammen mit ihren Initialisierungsdateien installiert:

![\[Terminal output showing Git repository initialization and npm install completion.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-init-app-example.png)


Ihre Projektstruktur könnte so aussehen:

![\[Project directory structure showing folders and files for an example CDK app.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-init-directories.png)


Sie werden feststellen, dass wir mehrere wichtige Verzeichnisse haben:
+ `bin`: Die erste BIN-Datei erstellt die App. Wir werden das in diesem Handbuch nicht behandeln.
+ `lib`: Das Verzeichnis lib enthält Ihre Stack-Dateien. Sie können sich Stack-Dateien als einzelne Ausführungseinheiten vorstellen. Konstrukte werden in unseren Stack-Dateien enthalten sein. Im Grunde sind dies Ressourcen für einen Dienst, der CloudFormation bei der Bereitstellung der App aktiviert wird. Hier wird der Großteil unserer Codierung stattfinden.
+ `node_modules`: Dieses Verzeichnis wurde von NPM erstellt und enthält alle Paketabhängigkeiten, die Sie mit dem `npm` Befehl installiert haben.

Unsere anfängliche Stack-Datei könnte etwa Folgendes enthalten:

```
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
// import * as sqs from 'aws-cdk-lib/aws-sqs';

export class ExampleCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // The code that defines your stack goes here

    // example resource
    // const queue = new sqs.Queue(this, 'ExampleCdkAppQueue', {
    //   visibilityTimeout: cdk.Duration.seconds(300)
    // });
  }
}
```

Dies ist der Boilerplate-Code zum Erstellen eines Stacks in unserer App. Der größte Teil unseres Codes in diesem Beispiel wird in den Geltungsbereich dieser Klasse fallen.

Um zu überprüfen, ob sich Ihre Stack-Datei in der App im Verzeichnis Ihrer App befindet, führen Sie den folgenden Befehl im Terminal aus:

```
cdk ls
```

Eine Liste deiner Stacks sollte erscheinen. Ist dies nicht der Fall, musst du die Schritte möglicherweise erneut ausführen oder in der offiziellen Dokumentation nach Hilfe suchen.

Wenn Sie Ihre Codeänderungen vor der Bereitstellung erstellen möchten, können Sie jederzeit den folgenden Befehl im Terminal ausführen:

```
npm run build
```

Und um die Änderungen vor der Bereitstellung zu sehen:

```
cdk diff
```

Bevor wir unseren Code zur Stack-Datei hinzufügen, führen wir einen Bootstrap durch. Bootstrapping ermöglicht es uns, Ressourcen für das CDK bereitzustellen, bevor die App bereitgestellt wird. [Weitere Informationen zu diesem Prozess finden Sie hier.](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) Um einen Bootstrap zu erstellen, lautet der Befehl:

```
cdk bootstrap aws://ACCOUNT-NUMBER/REGION
```

**Tipp**  
Für diesen Schritt sind mehrere IAM-Berechtigungen in Ihrem Konto erforderlich. Ihr Bootstrap wird verweigert, wenn Sie sie nicht haben. In diesem Fall müssen Sie möglicherweise unvollständige Ressourcen löschen, die durch den Bootstrap verursacht wurden, z. B. den von ihm generierten S3-Bucket.

Bootstrap wird mehrere Ressourcen bereitstellen. Die endgültige Nachricht wird so aussehen:

![\[Terminal output showing successful bootstrapping of an AWS environment.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-init-bootstrap-final.png)


Dies erfolgt einmal pro Konto pro Region, sodass Sie dies nicht oft tun müssen. Die Hauptressourcen des Bootstrap sind der CloudFormation Stack und der Amazon S3 S3-Bucket.

Der Amazon S3 S3-Bucket wird zum Speichern von Dateien und IAM-Rollen verwendet, die die für die Durchführung von Bereitstellungen erforderlichen Berechtigungen gewähren. Die erforderlichen Ressourcen werden in einem CloudFormation Stack definiert, dem sogenannten Bootstrap-Stack, der normalerweise benannt ist. `CDKToolkit` Wie jeder CloudFormation Stack erscheint er in der CloudFormation Konsole, sobald er bereitgestellt wurde:

![\[CDKToolkit stack with CREATE_COMPLETE status in CloudFormation console.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-init-bootstrap-cfn-console.png)


Das Gleiche gilt für den Bucket:

![\[S3 bucket details showing name, region, access settings, and creation date.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-init-bootstrap-bucket-console.png)


Um die Dienste, die wir benötigen, in unsere Stack-Datei zu importieren, können wir den folgenden Befehl verwenden:

```
npm install aws-cdk-lib # V2 command
```

**Tipp**  
Wenn Sie Probleme mit V2 haben, können Sie die einzelnen Bibliotheken mit V1-Befehlen installieren:  

```
npm install @aws-cdk/aws-appsync @aws-cdk/aws-dynamodb
```
Wir empfehlen dies nicht, da V1 veraltet ist.

## Implementierung eines CDK-Projekts — Schema
<a name="implementing-a-cdk-project-schema"></a>

Wir können jetzt mit der Implementierung unseres Codes beginnen. Zuerst müssen wir unser Schema erstellen. Sie können einfach eine `.graphql` Datei in Ihrer App erstellen:

```
mkdir schema
touch schema.graphql
```

In unserem Beispiel haben wir ein Verzeichnis auf oberster Ebene mit dem Namen hinzugefügt, das `schema` Folgendes enthält: `schema.graphql`

![\[File structure showing a schema folder containing schema.graphql file.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-schema-directory.png)


Lassen Sie uns in unser Schema ein einfaches Beispiel aufnehmen:

```
input CreatePostInput {
    title: String
    content: String
}

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

type Mutation {
    createPost(input: CreatePostInput!): Post
}

type Query {
    getPost: [Post]
}
```

Zurück in unserer Stack-Datei müssen wir sicherstellen, dass die folgenden Importdirektiven definiert sind:

```
import * as cdk from 'aws-cdk-lib';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';
```

Innerhalb der Klasse fügen wir Code hinzu, um unsere GraphQL-API zu erstellen und sie mit unserer `schema.graphql` Datei zu verbinden:

```
export class ExampleCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    
    // makes a GraphQL API
    const api = new appsync.GraphqlApi(this, 'post-apis', {
      name: 'api-to-process-posts',
      schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
    });
  }
}
```

Wir werden auch etwas Code hinzufügen, um die GraphQL-URL, den API-Schlüssel und die Region auszudrucken:

```
export class ExampleCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    
    // Makes a GraphQL API construct
    const api = new appsync.GraphqlApi(this, 'post-apis', {
      name: 'api-to-process-posts',
      schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
    });

    // Prints out URL
    new cdk.CfnOutput(this, "GraphQLAPIURL", {
      value: api.graphqlUrl
    });

    // Prints out the AppSync GraphQL API key to the terminal
    new cdk.CfnOutput(this, "GraphQLAPIKey", {
      value: api.apiKey || ''
    });

    // Prints out the stack region to the terminal
    new cdk.CfnOutput(this, "Stack Region", {
      value: this.region
    });
  }
}
```

An dieser Stelle werden wir unsere App erneut bereitstellen verwenden:

```
cdk deploy
```

Das ist das Ergebnis:

![\[Deployment output showing ExampleCdkAppStack details, including GraphQL API URL and stack region.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-schema.png)


Es scheint, dass unser Beispiel erfolgreich war, aber schauen wir uns die AWS AppSync Konsole an, um zu bestätigen:

![\[GraphQL interface showing successful API request with response data displayed.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-schema-result-1.png)


Es scheint, dass unsere API erstellt wurde. Jetzt überprüfen wir das an die API angehängte Schema:

![\[GraphQL schema defining CreatePostInput, Post type, Mutation, and Query operations.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-schema-result-2.png)


Dies scheint mit unserem Schemacode übereinzustimmen, es war also erfolgreich. Eine andere Möglichkeit, dies aus Sicht der Metadaten zu bestätigen, besteht darin, sich den CloudFormation Stack anzusehen:

![\[CloudFormation stack showing ExampleCdkAppStack update complete and CDKToolkit creation complete.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-schema-result-3.png)


Wenn wir unsere CDK-App bereitstellen, werden Ressourcen CloudFormation wie der Bootstrap aktiviert. Jeder Stapel in unserer App wird 1:1 einem CloudFormation Stapel zugeordnet. Wenn Sie zum Stack-Code zurückkehren, wurde der Stackname aus dem Klassennamen `ExampleCdkAppStack` übernommen. Sie können die erstellten Ressourcen, die auch unseren Namenskonventionen entsprechen, in unserem GraphQL-API-Konstrukt sehen:

![\[Expanded view of post-apis resource showing Schema, DefaultApiKey, and CDKMetadata.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-schema-result-4.png)


## Implementierung eines CDK-Projekts — Datenquelle
<a name="implementing-a-cdk-project-data-source"></a>

Als Nächstes müssen wir unsere Datenquelle hinzufügen. In unserem Beispiel wird eine DynamoDB-Tabelle verwendet. Innerhalb der Stack-Klasse fügen wir etwas Code hinzu, um eine neue Tabelle zu erstellen:

```
export class ExampleCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Makes a GraphQL API construct
    const api = new appsync.GraphqlApi(this, 'post-apis', {
      name: 'api-to-process-posts',
      schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
    });

    //creates a DDB table
    const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
      partitionKey: {
        name: 'id',
        type: dynamodb.AttributeType.STRING,
      },
    });

    // Prints out URL
    new cdk.CfnOutput(this, "GraphQLAPIURL", {
      value: api.graphqlUrl
    });

    // Prints out the AppSync GraphQL API key to the terminal
    new cdk.CfnOutput(this, "GraphQLAPIKey", {
      value: api.apiKey || ''
    });

    // Prints out the stack region to the terminal
    new cdk.CfnOutput(this, "Stack Region", {
      value: this.region
    });
  }
}
```

Lassen Sie uns an dieser Stelle erneut bereitstellen:

```
cdk deploy
```

Wir sollten in der DynamoDB-Konsole nach unserer neuen Tabelle suchen:

![\[DynamoDB console showing ExampleCdkAppStack-poststable as Active with Provisioned capacity.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-ddb-result-1.png)


Unser Stack-Name ist korrekt und der Tabellenname entspricht unserem Code. Wenn wir unseren CloudFormation Stack erneut überprüfen, sehen wir jetzt die neue Tabelle:

![\[Expanded view of a logical ID in CloudFormation showing post-apis, posts-table, and CDKMetadata.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-ddb-result-2.png)


## Implementierung eines CDK-Projekts - Resolver
<a name="implementing-a-cdk-project-resolver"></a>

In diesem Beispiel werden zwei Resolver verwendet: einer zum Abfragen der Tabelle und einer zum Hinzufügen. Da wir Pipeline-Resolver verwenden, müssen wir zwei Pipeline-Resolver mit jeweils einer Funktion deklarieren. In der Abfrage fügen wir den folgenden Code hinzu:

```
export class ExampleCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Makes a GraphQL API construct
    const api = new appsync.GraphqlApi(this, 'post-apis', {
      name: 'api-to-process-posts',
      schema: appsync.SchemaFile.fromAsset('schema/schema.graphql'),
    });

    //creates a DDB table
    const add_ddb_table = new dynamodb.Table(this, 'posts-table', {
      partitionKey: {
        name: 'id',
        type: dynamodb.AttributeType.STRING,
      },
    });

    // Creates a function for query
    const add_func = new appsync.AppsyncFunction(this, 'func-get-post', {
      name: 'get_posts_func_1',
      api,
      dataSource: api.addDynamoDbDataSource('table-for-posts', add_ddb_table),
      code: appsync.Code.fromInline(`
          export function request(ctx) {
          return { operation: 'Scan' };
          }

          export function response(ctx) {
          return ctx.result.items;
          }
  `),
      runtime: appsync.FunctionRuntime.JS_1_0_0,
    });

    // Creates a function for mutation
    const add_func_2 = new appsync.AppsyncFunction(this, 'func-add-post', {
      name: 'add_posts_func_1',
      api,
      dataSource: api.addDynamoDbDataSource('table-for-posts-2', add_ddb_table),
      code: appsync.Code.fromInline(`
          export function request(ctx) {
            return {
            operation: 'PutItem',
            key: util.dynamodb.toMapValues({id: util.autoId()}),
            attributeValues: util.dynamodb.toMapValues(ctx.args.input),
            };
          }

          export function response(ctx) {
            return ctx.result;
          }
      `),
      runtime: appsync.FunctionRuntime.JS_1_0_0,
    });

    // Adds a pipeline resolver with the get function
    new appsync.Resolver(this, 'pipeline-resolver-get-posts', {
      api,
      typeName: 'Query',
      fieldName: 'getPost',
      code: appsync.Code.fromInline(`
          export function request(ctx) {
          return {};
          }

          export function response(ctx) {
          return ctx.prev.result;
          }
  `),
      runtime: appsync.FunctionRuntime.JS_1_0_0,
      pipelineConfig: [add_func],
    });

    // Adds a pipeline resolver with the create function
    new appsync.Resolver(this, 'pipeline-resolver-create-posts', {
      api,
      typeName: 'Mutation',
      fieldName: 'createPost',
      code: appsync.Code.fromInline(`
          export function request(ctx) {
          return {};
          }

          export function response(ctx) {
          return ctx.prev.result;
          }
  `),
      runtime: appsync.FunctionRuntime.JS_1_0_0,
      pipelineConfig: [add_func_2],
    });

    // Prints out URL
    new cdk.CfnOutput(this, "GraphQLAPIURL", {
      value: api.graphqlUrl
    });

    // Prints out the AppSync GraphQL API key to the terminal
    new cdk.CfnOutput(this, "GraphQLAPIKey", {
      value: api.apiKey || ''
    });

    // Prints out the stack region to the terminal
    new cdk.CfnOutput(this, "Stack Region", {
      value: this.region
    });
  }
}
```

In diesem Snippet haben wir einen Pipeline-Resolver hinzugefügt, an den eine Funktion namens `func-add-post` angehängt ist. `pipeline-resolver-create-posts` Dies ist der Code, der der Tabelle `Posts` hinzugefügt wird. Der andere Pipeline-Resolver wurde `pipeline-resolver-get-posts` mit einer Funktion aufgerufen`func-get-post`, die zur Tabelle `Posts` hinzugefügte Daten abruft.

Wir werden das bereitstellen, um es dem AWS AppSync Service hinzuzufügen:

```
cdk deploy
```

Schauen wir in der AWS AppSync Konsole nach, ob sie an unsere GraphQL-API angehängt waren:

![\[GraphQL API schema showing mutation and query fields with Pipeline resolvers.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-1.png)


Es scheint richtig zu sein. Im Code wurden diese beiden Resolver an die von uns erstellte GraphQL-API angehängt (gekennzeichnet durch den `api` Props-Wert, der sowohl in den Resolvern als auch in den Funktionen vorhanden ist). In der GraphQL-API wurden die Felder, an die wir unsere Resolver angehängt haben, auch in den Requisiten angegeben (definiert durch die `typename` und `fieldname` -Requisiten in jedem Resolver).

Schauen wir uns an, ob der Inhalt der Resolver korrekt ist, beginnend mit: `pipeline-resolver-get-posts`

![\[Code snippet showing request and response functions in a resolver, with an arrow pointing to them.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-2.png)


Die Vorher- und Nachher-Handler entsprechen unserem `code` Requisitenwert. Wir können auch sehen, dass eine Funktion aufgerufen wurde`add_posts_func_1`, die dem Namen der Funktion entspricht, die wir im Resolver angehängt haben.

Schauen wir uns den Codeinhalt dieser Funktion an:

![\[Function code showing request and response methods for a PutItem operation.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-3.png)


Dies entspricht den `code` Requisiten der `add_posts_func_1` Funktion. Unsere Anfrage wurde erfolgreich hochgeladen, also schauen wir uns die Anfrage an:

![\[Resolver code with request and response functions, and a get_posts_func_1 function listed below.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-4.png)


Diese stimmen auch mit dem Code überein. Wenn wir uns ansehen`get_posts_func_1`:

![\[Code snippet showing two exported functions: request returning 'Scan' operation and response returning items.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-5.png)


Alles scheint an seinem Platz zu sein. Um dies aus Sicht der Metadaten zu bestätigen, können wir unseren Stack CloudFormation erneut einchecken:

![\[List of logical IDs for AWS resources including API, table, functions, and pipelines.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-deploy-resolver-result-6.png)


Jetzt müssen wir diesen Code testen, indem wir einige Anfragen ausführen.

## Implementierung eines CDK-Projekts — Anfragen
<a name="implementing-a-cdk-project-requests"></a>

Um unsere App in der AWS AppSync Konsole zu testen, haben wir eine Abfrage und eine Mutation durchgeführt:

![\[GraphQL code snippet showing a query to get post details and a mutation to create a post.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-request-1.png)


`MyMutation`enthält eine `createPost` Operation mit den Argumenten `1970-01-01T12:30:00.000Z` und`first post`. Sie gibt den Wert `date` und zurück`title`, den wir übergeben haben, sowie den automatisch generierten `id` Wert. Das Ausführen der Mutation ergibt das Ergebnis:

```
{
  "data": {
    "createPost": {
      "date": "1970-01-01T12:30:00.000Z",
      "id": "4dc1c2dd-0aa3-4055-9eca-7c140062ada2",
      "title": "first post"
    }
  }
}
```

Wenn wir die DynamoDB-Tabelle schnell überprüfen, können wir unseren Eintrag in der Tabelle sehen, wenn wir sie scannen:

![\[DynamoDB table entry showing id, date, and title fields for a single item.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/cdk-code-request-2.png)


Wenn wir in der AWS AppSync Konsole die Abfrage ausführen, um dies abzurufen`Post`, erhalten wir das folgende Ergebnis:

```
{
  "data": {
    "getPost": [
      {
        "id": "9f62c4dd-49d5-48d5-b835-143284c72fe0",
        "date": "1970-01-01T12:30:00.000Z",
        "title": "first post"
      }
    ]
  }
}
```

# Verwendung von Abonnements für Echtzeit-Datenanwendungen in AWS AppSync
<a name="aws-appsync-real-time-data"></a>

**Wichtig**  
Ab dem 13. März 2025 können Sie WebSockets mithilfe von AWS AppSync Events eine PubSub Echtzeit-API erstellen. Weitere Informationen finden Sie unter [Ereignisse veröffentlichen über WebSocket](https://docs.aws.amazon.com/appsync/latest/eventapi/publish-websocket.html) im *AWS AppSync Events Developer Guide*.

AWS AppSyncermöglicht es Ihnen, Abonnements zu nutzen, um Live-Anwendungsupdates, Push-Benachrichtigungen usw. zu implementieren. Wenn Clients die GraphQL-Abonnementvorgänge aufrufen, wird automatisch eine sichere WebSocket Verbindung hergestellt und aufrechterhalten von. AWS AppSync Anwendungen können dann Daten in Echtzeit von einer Datenquelle an Abonnenten verteilen und gleichzeitig die Verbindungs- und Skalierungsanforderungen der Anwendung AWS AppSync kontinuierlich verwalten. In den folgenden Abschnitten erfahren Sie, wie Abonnements AWS AppSync funktionieren.

## GraphQL-Schemaabonnementanweisungen
<a name="graphql-schema-subscription-directives"></a>

Abonnements in AWS AppSync werden als Reaktion auf eine Mutation aufgerufen. Das bedeutet, dass Sie jede Datenquelle in AWS AppSync Echtzeit erstellen können, indem Sie eine GraphQL-Schemadirektive für eine Mutation angeben.

Die AWS Amplify Clientbibliotheken kümmern sich automatisch um die Verwaltung der Abonnementverbindungen. Die Bibliotheken verwenden Pure WebSockets als Netzwerkprotokoll zwischen dem Client und dem Dienst.

**Anmerkung**  
Um die Autorisierung bei der Verbindung mit einem Abonnement zu steuern, können Sie AWS Identity and Access Management (IAM), AWS Lambda Amazon Cognito Cognito-Identitätspools oder Amazon Cognito Cognito-Benutzerpools für die Autorisierung auf Feldebene verwenden. Für detaillierte Zugriffskontrollen für Abonnements können Sie Resolver an Ihre Abonnementfelder anhängen und anhand der Identität des Anrufers und der Datenquellen eine Logik ausführen. AWS AppSync Weitere Informationen finden Sie unter [Konfiguration von Autorisierung und Authentifizierung zur Sicherung Ihres GraphQL APIs](security-authz.md).

Abonnements werden durch Mutationen ausgelöst und die Mutationsauswahlmenge wird an Abonnenten gesendet.

Das folgende Beispiel zeigt, wie Sie mit GraphQL-Abonnements arbeiten. Es gibt keine Datenquelle an, da es sich bei der Datenquelle um Lambda, Amazon DynamoDB oder Amazon Service handeln könnte. OpenSearch 

Um mit Abonnements zu beginnen, müssen Sie Ihrem Schema wie folgt einen Abonnement-Einstiegspunkt hinzufügen:

```
schema {
    query: Query
    mutation: Mutation
    subscription: Subscription
}
```

Angenommen, Sie haben eine Blog-Website und möchten neue Blogs sowie Änderungen an vorhandenen Blogs abonnieren. Fügen Sie zu diesem Zweck folgende `Subscription`-Definition dem Schema hinzu:

```
type Subscription {
    addedPost: Post
    updatedPost: Post
    deletedPost: Post
}
```

Nehmen wir außerdem an, Sie haben die folgenden Mutationen:

```
type Mutation {
    addPost(id: ID! author: String! title: String content: String url: String): Post!
    updatePost(id: ID! author: String! title: String content: String url: String ups: Int! downs: Int! expectedVersion: Int!): Post!
    deletePost(id: ID!): Post!
}
```

Sie können diese Felder in Echtzeitfelder umwandeln, indem Sie folgendermaßen eine `@aws_subscribe(mutations: ["mutation_field_1", "mutation_field_2"])`-Richtlinie für jedes Abonnement hinzufügen, für das Sie Benachrichtigungen erhalten möchten:

```
type Subscription {
    addedPost: Post
    @aws_subscribe(mutations: ["addPost"])
    updatedPost: Post
    @aws_subscribe(mutations: ["updatePost"])
    deletedPost: Post
    @aws_subscribe(mutations: ["deletePost"])
}
```

Da das eine Reihe von Mutationseingaben `@aws_subscribe(mutations: ["",..,""])` benötigt, können Sie mehrere Mutationen angeben, wodurch ein Abonnement initiiert wird. Wenn Sie das Abonnement von einem Client aus initiieren, sieht Ihre GraphQL-Abfrage möglicherweise wie folgt aus:

```
subscription NewPostSub {
    addedPost {
        __typename
        version
        title
        content
        author
        url
    }
}
```

Diese Abonnementabfrage wird für Client-Verbindungen und Tools benötigt.

Beim reinen WebSockets Client erfolgt die Filterung der Auswahlsätze pro Client, da jeder Client seinen eigenen Auswahlsatz definieren kann. In diesem Fall muss der Abonnementauswahlsatz eine Teilmenge des Mutationsauswahlsatzes sein. Beispiel: Abonnement `addPost(...){id author title url version}`, das mit Mutation `addedPost{author title}` verknüpft ist, erhält nur den Autor und den Titel des Beitrags. Die anderen Felder werden nicht empfangen. Wenn der Mutation jedoch der Autor in ihrem Auswahlsatz fehlte, erhält der Abonnent einen `null`-Wert für das Autorenfeld (oder einen Fehler, falls das Autorenfeld im Schema als erforderlich/nicht NULL definiert ist).

Der Abonnement-Auswahlsatz ist bei der Verwendung von Pure unerlässlich WebSockets. Wenn ein Feld im Abonnement nicht explizit definiert ist, wird AWS AppSync das Feld nicht zurückgegeben.

Im vorherigen Beispiel hatten die Abonnements keine Argumente. Angenommen, Ihr Schema sieht wie folgt aus:

```
type Subscription {
    updatedPost(id:ID! author:String): Post
    @aws_subscribe(mutations: ["updatePost"])
}
```

In diesem Fall definiert der Client ein Abonnement wie folgt:

```
subscription UpdatedPostSub {
    updatedPost(id:"XYZ", author:"ABC") {
        title
        content
    }
}
```

Der Rückgabetyp eines `subscription`-Felds in Ihrem Schema muss dem Rückgabetyp des zugehörigen Mutationsfelds entsprechen. Im vorherigen Beispiel war dies als `addPost` und `addedPost` dargestellt, zurückgegeben als `Post`-Typ.

Informationen zum Einrichten von Abonnements auf dem Client finden Sie unter[Erstellen einer Client-Anwendung mit dem Amplify-Client](building-a-client-app.md).

## Abonnementargumente verwenden
<a name="using-subscription-arguments"></a>

Ein wichtiger Teil der Verwendung von GraphQL-Abonnements besteht darin, zu verstehen, wann und wie Argumente verwendet werden. Sie können subtile Änderungen vornehmen, um zu ändern, wie und wann Clients über aufgetretene Mutationen informiert werden sollen. Sehen Sie sich dazu das Beispielschema aus dem Schnellstart-Kapitel an, in dem „Todos“ erstellt wird. Für dieses Beispielschema sind die folgenden Mutationen definiert:

```
type Mutation {
    createTodo(input: CreateTodoInput!): Todo
    updateTodo(input: UpdateTodoInput!): Todo
    deleteTodo(input: DeleteTodoInput!): Todo
}
```

Im Standardbeispiel können Clients Updates für alle abonnieren, `Todo` indem sie das `onUpdateTodo` `subscription` ohne Argumente verwenden:

```
subscription OnUpdateTodo {
  onUpdateTodo {
    description
    id
    name
    when
  }
}
```

Sie können Ihre `subscription` anhand ihrer Argumente filtern. Um beispielsweise nur eine auszulösen, `subscription` wenn eine `todo` mit einem bestimmten aktualisiert `ID` wird, geben Sie den folgenden `ID` Wert an:

```
subscription OnUpdateTodo {
  onUpdateTodo(id: "a-todo-id") {
    description
    id
    name
    when
  }
}
```

Sie können auch mehrere Argumente übergeben. Im Folgenden wird beispielsweise gezeigt, `subscription` wie Sie über `Todo` Aktualisierungen an einem bestimmten Ort und zu einer bestimmten Zeit benachrichtigt werden können:

```
subscription todosAtHome {
  onUpdateTodo(when: "tomorrow", where: "at home") {
    description
    id
    name
    when
    where
  }
}
```

Beachten Sie, dass alle Argumente optional sind. Wenn Sie in Ihrem keine Argumente angeben`subscription`, abonnieren Sie alle `Todo` Updates, die in Ihrer Anwendung auftreten. Sie könnten jedoch Ihre Felddefinition aktualisieren, sodass das `ID` Argument erforderlich `subscription` ist. Dies würde die Antwort eines bestimmten `todo` statt aller `todo` s erzwingen:

```
onUpdateTodo(
  id: ID!,
  name: String,
  when: String,
  where: String,
  description: String
): Todo
```

### Argument-Null-Wert hat Bedeutung
<a name="argument-null-value-has-meaning"></a>

Bei einer Abonnementabfrage filtert ein `null` Argumentwert die Ergebnisse anders AWS AppSync, als wenn das Argument vollständig weggelassen wird.

Kehren wir zum Todos-API-Beispiel zurück, in dem wir Todos erstellen könnten. Sehen Sie sich das Beispielschema aus dem Schnellstart-Kapitel an.

Lassen Sie uns unser Schema so ändern, dass es ein neues `owner` Feld für den `Todo` Typ enthält, das beschreibt, wer der Eigentümer ist. Das `owner` Feld ist nicht erforderlich und kann nur aktiviert werden`UpdateTodoInput`. Sehen Sie sich die folgende vereinfachte Version des Schemas an:

```
type Todo {
  id: ID!
  name: String!
  when: String!
  where: String!
  description: String!
  owner: String
}

input CreateTodoInput {
  name: String!
  when: String!
  where: String!
  description: String!
}

input UpdateTodoInput {
  id: ID!
  name: String
  when: String
  where: String
  description: String
  owner: String
}

type Subscription {
    onUpdateTodo(
        id: ID,
        name: String,
        when: String,
        where: String,
        description: String
    ): Todo @aws_subscribe(mutations: ["updateTodo"])
}
```

Das folgende Abonnement gibt alle `Todo` Updates zurück:

```
subscription MySubscription {
  onUpdateTodo {
    description
    id
    name
    when
    where
  }
}
```

Wenn Sie das vorherige Abonnement ändern, um das Feldargument hinzuzufügen`owner: null`, stellen Sie jetzt eine andere Frage. Dieses Abonnement registriert jetzt den Client, um über alle `Todo` Updates informiert zu werden, für die kein Eigentümer angegeben wurde.

```
subscription MySubscription {
  onUpdateTodo(owner: null) {
    description
    id
    name
    when
    where
  }
}
```

**Anmerkung**  
**Seit dem 1. Januar 2022 WebSockets ist MQTT over nicht mehr als Protokoll für GraphQL-Abonnements in verfügbar. AWS AppSync APIs Pure WebSockets ist das einzige Protokoll, das in unterstützt wird. AWS AppSync**  
Clients, die auf dem AWS AppSync SDK oder den Amplify-Bibliotheken basieren und nach November 2019 veröffentlicht wurden, verwenden WebSockets standardmäßig automatisch Pure. Durch das Upgrade der Clients auf die neueste Version können sie die Pure WebSockets Engine verwenden AWS AppSync.  
Pure WebSockets bietet eine größere Nutzlast (240 KB), eine größere Auswahl an Client-Optionen und verbesserte CloudWatch Metriken. Weitere Informationen zur Verwendung von Pure WebSocket Clients finden Sie unter[Aufbau eines Echtzeit-Clients in WebSocket AWS AppSync](real-time-websocket-client.md).

# Generisches pub/sub APIs Powered by Serverless WebSockets in AWS AppSync
<a name="aws-appsync-real-time-create-generic-api-serverless-websocket"></a>

**Wichtig**  
Ab dem 13. März 2025 können Sie WebSockets mithilfe von AWS AppSync Events eine PubSub Echtzeit-API erstellen. Weitere Informationen finden Sie unter [Ereignisse veröffentlichen über WebSocket](https://docs.aws.amazon.com/appsync/latest/eventapi/publish-websocket.html) im *AWS AppSync Events Developer Guide*.

Bei einigen Anwendungen ist lediglich Simple erforderlich WebSocket APIs , bei dem sich die Kunden einen bestimmten Kanal oder ein bestimmtes Thema anhören. Generische JSON-Daten ohne spezifische Form oder stark typisierte Anforderungen können nach einem einfachen Publish-Subscribe-Muster (Pub/Sub) an Kunden weitergegeben werden, die sich einen dieser Kanäle anhören.

Wird verwendet AWS AppSync , um einfache Implementierungen pub/sub WebSocket APIs mit wenig bis gar keinen GraphQL-Kenntnissen innerhalb von Minuten durchzuführen, indem GraphQL-Code sowohl auf dem API-Backend als auch auf der Clientseite automatisch generiert wird.

## Pub-Sub erstellen und konfigurieren APIs
<a name="aws-appsync-real-time-enhanced-filtering-using-pub-sub-apis"></a>

Gehen Sie zunächst wie folgt vor: 

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **Dashboard** **Create API (API erstellen)** aus.

1. Wählen Sie auf dem nächsten Bildschirm **Create a real-time API** und dann **Next** aus.

1. Geben Sie einen benutzerfreundlichen Namen für Ihre pub/sub API ein.

1. Sie können [private API-Funktionen](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html) aktivieren, wir empfehlen jedoch, dies vorerst auszuschalten. Wählen Sie **Weiter** aus.

1. Sie können wählen, ob Sie mit automatisch eine funktionierende pub/sub API generieren möchten WebSockets. Wir empfehlen, diese Funktion vorerst ebenfalls auszuschalten. Wählen Sie **Weiter** aus.

1. Wählen Sie **Create API** und warten Sie dann einige Minuten. Eine neue vorkonfigurierte AWS AppSync Pub/Sub-API wird in Ihrem Konto erstellt. AWS 

Die API verwendet AWS AppSync die integrierten lokalen Resolver (weitere Informationen zur Verwendung lokaler Resolver finden Sie unter [Tutorial: Lokale Resolver](https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-local-resolvers-js.html) im *AWS AppSync Entwicklerhandbuch*), um mehrere temporäre pub/sub Kanäle und WebSocket Verbindungen zu verwalten. Dabei werden Daten automatisch nur auf der Grundlage des Kanalnamens an abonnierte Clients übermittelt und gefiltert. API-Aufrufe werden mit einem API-Schlüssel autorisiert.

Nach der Bereitstellung der API stehen Ihnen einige zusätzliche Schritte zur Generierung von Client-Code und dessen Integration in Ihre Client-Anwendung zur Verfügung. Als Beispiel für die schnelle Integration eines Clients wird in diesem Handbuch eine einfache React-Webanwendung verwendet.

1. Erstellen Sie zunächst eine Boilerplate-React-App mit [NPM](https://www.npmjs.com/get-npm) auf Ihrem lokalen Computer:

   ```
   $ npx create-react-app mypubsub-app 
   $ cd mypubsub-app
   ```
**Anmerkung**  
In diesem Beispiel werden die [Amplify-Bibliotheken](https://docs.amplify.aws/lib/) verwendet, um Clients mit der Backend-API zu verbinden. Es ist jedoch nicht erforderlich, ein Amplify CLI-Projekt lokal zu erstellen. Während React in diesem Beispiel der Client der Wahl ist, unterstützen Amplify-Bibliotheken auch iOS-, Android- und Flutter-Clients und bieten dieselben Funktionen in diesen unterschiedlichen Laufzeiten. [Die unterstützten Amplify-Clients bieten einfache Abstraktionen für die Interaktion mit AWS AppSync GraphQL-API-Backends mit wenigen Codezeilen, einschließlich integrierter WebSocket Funktionen, die vollständig mit dem Echtzeitprotokoll kompatibel sind:AWS AppSync WebSocket ](https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html)  

   ```
   $ npm install @aws-amplify/api
   ```

1. Wählen Sie in der AWS AppSync Konsole dann **Herunterladen** aus **JavaScript**, um eine einzelne Datei mit den API-Konfigurationsdetails und dem generierten GraphQL-Operationscode herunterzuladen.

1. Kopieren Sie die heruntergeladene Datei in den `/src` Ordner in Ihrem React-Projekt.

1. Ersetzen Sie als Nächstes den Inhalt der vorhandenen `src/App.js` Boilerplate-Datei durch den in der Konsole verfügbaren Beispiel-Client-Code.

1. Verwenden Sie den folgenden Befehl, um die Anwendung lokal zu starten:

   ```
   $ npm start
   ```

1. Um das Senden und Empfangen von Echtzeitdaten zu testen, öffnen Sie zwei Browserfenster und greifen Sie darauf zu*localhost:3000*. Die Beispielanwendung ist so konfiguriert, dass sie generische JSON-Daten an einen fest codierten Kanal mit dem Namen *robots* sendet.

1.  **Geben Sie in einem der Browserfenster den folgenden JSON-Blob in das Textfeld ein und klicken Sie dann auf Senden:** 

   ```
   {
     "robot":"r2d2",
     "planet": "tatooine"
   }
   ```

Beide Browserinstanzen haben den *robots* Kanal abonniert und empfangen die veröffentlichten Daten in Echtzeit, die unten in der Webanwendung angezeigt werden:

![\[Beispiel für eine React-App für API pub/sub\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/pub-sub-react.png)


Der gesamte erforderliche GraphQL-API-Code, einschließlich des Schemas, der Resolver und der Operationen, wird automatisch generiert, um einen generischen pub/sub Anwendungsfall zu ermöglichen. Im Backend werden Daten mit einer GraphQL-Mutation wie AWS AppSync der folgenden auf dem Echtzeit-Endpunkt veröffentlicht:

```
mutation PublishData {
    publish(data: "{\"msg\": \"hello world!\"}", name: "channel") {
        data
        name
    }
}
```

Abonnenten greifen mit einem entsprechenden GraphQL-Abonnement auf die veröffentlichten Daten zu, die an den jeweiligen temporären Kanal gesendet wurden:

```
subscription SubscribeToData {
    subscribe(name:"channel") {
        name
        data
    }
}
```

## Implementierung von Pub-Sub in bestehende Anwendungen APIs
<a name="aws-appsync-real-time-enhanced-filtering-existing-apps"></a>

Falls Sie nur eine Echtzeitfunktion in einer vorhandenen Anwendung implementieren müssen, kann diese generische pub/sub API-Konfiguration problemlos in jede Anwendung oder API-Technologie integriert werden. Die Verwendung eines einzigen API-Endpunkts für den sicheren Zugriff, die Bearbeitung und Kombination von Daten aus einer oder mehreren Datenquellen in einem einzigen Netzwerkaufruf mit GraphQL bietet zwar Vorteile, es ist jedoch nicht erforderlich, eine bestehende REST-basierte Anwendung von Grund auf neu zu konvertieren oder neu zu erstellen, um die Echtzeitfunktionen nutzen zu können. AWS AppSync Sie könnten beispielsweise einen vorhandenen CRUD-Workload in einem separaten API-Endpunkt haben, wobei Clients Nachrichten oder Ereignisse von der vorhandenen Anwendung an die generische pub/sub API nur in Echtzeit und zu bestimmten pub/sub Zwecken senden und empfangen. 

# Definition erweiterter Abonnementfilter in AWS AppSync
<a name="aws-appsync-real-time-enhanced-filtering"></a>

**Wichtig**  
Ab dem 13. März 2025 können Sie WebSockets mithilfe von AWS AppSync Events eine PubSub Echtzeit-API erstellen. Weitere Informationen finden Sie unter [Ereignisse veröffentlichen über WebSocket](https://docs.aws.amazon.com/appsync/latest/eventapi/publish-websocket.html) im *AWS AppSync Events Developer Guide*.

In AWS AppSync können Sie die Geschäftslogik für die Datenfilterung im Backend direkt in den GraphQL-API-Abonnement-Resolvern definieren und aktivieren, indem Sie Filter verwenden, die zusätzliche logische Operatoren unterstützen. Im Gegensatz zu den Abonnementargumenten, die in der Abonnementabfrage im Client definiert sind, können Sie diese Filter konfigurieren. Weitere Hinweise zur Verwendung von Abonnementargumenten finden Sie unter[Abonnementargumente verwenden](aws-appsync-real-time-data.md#using-subscription-arguments). Eine Liste der Operatoren finden Sie unter[AWS AppSync Referenz zum Hilfsprogramm für Resolver-Mapping-Vorlagen](resolver-util-reference.md).

Für die Zwecke dieses Dokuments unterteilen wir die Echtzeit-Datenfilterung in die folgenden Kategorien:
+ **Grundlegendes Filtern** — Filterung auf der Grundlage von vom Kunden definierten Argumenten in der Abonnementabfrage.
+ **Verbesserte Filterung — Filterung** auf der Grundlage einer Logik, die zentral im AWS AppSync Service-Backend definiert ist.

In den folgenden Abschnitten wird erklärt, wie erweiterte Abonnementfilter konfiguriert werden und wie sie in der Praxis angewendet werden.

## Definieren von Abonnements in Ihrem GraphQL-Schema
<a name="aws-appsync-real-time-enhanced-filtering-using-subscription-filters"></a>

Um erweiterte Abonnementfilter zu verwenden, definieren Sie das Abonnement im GraphQL-Schema und definieren dann den erweiterten Filter mithilfe einer Filtererweiterung. Um zu veranschaulichen, wie die erweiterte Abonnementfilterung funktioniert AWS AppSync, verwenden Sie als Beispiel das folgende GraphQL-Schema, das eine Ticket-Management-System-API definiert:

```
type Ticket {
	id: ID
	createdAt: AWSDateTime
	content: String
	severity: Int
	priority: Priority
	category: String
	group: String
	status: String
	
}

type Mutation {
	createTicket(input: TicketInput): Ticket
}

type Query {
	getTicket(id: ID!): Ticket
}

type Subscription {
	onSpecialTicketCreated: Ticket @aws_subscribe(mutations: ["createTicket"])
	onGroupTicketCreated(group: String!): Ticket @aws_subscribe(mutations: ["createTicket"])
}



enum Priority {
	none
	lowest
	low
	medium
	high
	highest
}

input TicketInput {
	content: String
	severity: Int
	priority: Priority
	category: String
	group: String
```

Angenommen, Sie erstellen eine `NONE` Datenquelle für Ihre API und fügen dann mithilfe dieser Datenquelle einen Resolver an die `createTicket` Mutation an. Ihre Handler könnten so aussehen:

```
import { util } from '@aws-appsync/utils';

export function request(ctx) {
	return {
		payload: {
			id: util.autoId(),
			createdAt: util.time.nowISO8601(),
			status: 'pending',
			...ctx.args.input,
		},
	};
}

export function response(ctx) {
	return ctx.result;
}
```

**Anmerkung**  
Verbesserte Filter werden im Handler des GraphQL-Resolvers in einem bestimmten Abonnement aktiviert. Weitere Informationen finden Sie in der [Resolver-Referenz](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-js-version.html).

Um das Verhalten des erweiterten Filters zu implementieren, müssen Sie die `extensions.setSubscriptionFilter()` Funktion verwenden, um einen Filterausdruck zu definieren, der anhand veröffentlichter Daten aus einer GraphQL-Mutation ausgewertet wird, an der die abonnierten Clients interessiert sein könnten. [Weitere Informationen zu den Filtererweiterungen finden Sie unter Erweiterungen.](https://docs.aws.amazon.com//appsync/latest/devguide/extensions-js.html)

Im folgenden Abschnitt wird erklärt, wie Sie Filtererweiterungen verwenden, um erweiterte Filter zu implementieren.

## Erstellen erweiterter Abonnementfilter mithilfe von Filtererweiterungen
<a name="aws-appsync-real-time-enhanced-filtering-defining-filters"></a>

Verbesserte Filter werden in JSON in den Antworthandler der Resolver des Abonnements geschrieben. Filter können in einer Liste zusammengefasst werden, die als a `filterGroup` bezeichnet wird. Filter werden mithilfe von mindestens einer Regel definiert, die jeweils Felder, Operatoren und Werte enthält. Definieren wir einen neuen Resolver`onSpecialTicketCreated`, der einen erweiterten Filter einrichtet. Sie können mehrere Regeln in einem Filter konfigurieren, die mithilfe der UND-Logik ausgewertet werden, während mehrere Filter in einer Filtergruppe mithilfe der OR-Logik ausgewertet werden:

```
import { util, extensions } from '@aws-appsync/utils';

export function request(ctx) {
	// simplfy return null for the payload
	return { payload: null };
}

export function response(ctx) {
	const filter = {
		or: [
			{ severity: { ge: 7 }, priority: { in: ['high', 'medium'] } },
			{ category: { eq: 'security' }, group: { in: ['admin', 'operators'] } },
		],
	};
	extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter));

  // important: return null in the response
	return null;
}
```

Basierend auf den im vorherigen Beispiel definierten Filtern werden wichtige Tickets automatisch an abonnierte API-Clients weitergeleitet, wenn ein Ticket erstellt wird mit:
+ `priority`Stufe oder `high` `medium`

  AND 
+ `severity`Stufe größer oder gleich `7` (`ge`)

ODER 
+ `classification`Ticket gesetzt auf `Security` 

  AND 
+ `group`Die Zuweisung ist auf `admin` oder gesetzt `operators`

![\[Beispiel für eine Ticketfilterabfrage\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/aws-priority-example.png)


Im Abonnement-Resolver definierte Filter (erweiterte Filterung) haben Vorrang vor Filtern, die nur auf Abonnementargumenten basieren (grundlegende Filterung). Weitere Informationen zur Verwendung von Abonnementargumenten finden Sie unter [Abonnementargumente verwenden](https://docs.aws.amazon.com//appsync/latest/devguide/aws-appsync-real-time-data.html#using-subscription-arguments)).

Wenn ein Argument im GraphQL-Schema des Abonnements definiert und erforderlich ist, erfolgt die Filterung auf der Grundlage des angegebenen Arguments nur, wenn das Argument in der Regel in der Methode des Resolvers definiert ist`extensions.setSubscriptionFilter()`. Wenn der Abonnement-Resolver jedoch keine `extensions` Filtermethoden enthält, werden die im Client definierten Argumente nur für die grundlegende Filterung verwendet. Sie können die Standardfilterung und die erweiterte Filterung nicht gleichzeitig verwenden.

Sie können die [`context`Variable](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) in der Filtererweiterungslogik des Abonnements verwenden, um auf Kontextinformationen zur Anfrage zuzugreifen. Wenn Sie beispielsweise Amazon Cognito User Pools, OIDC oder benutzerdefinierte Lambda-Autorisierer für die Autorisierung verwenden, können Sie Informationen über Ihre Benutzer abrufen, sobald das Abonnement eingerichtet wird. `context.identity` Sie können diese Informationen verwenden, um Filter auf der Grundlage der Identität Ihrer Benutzer einzurichten.

Gehen Sie nun davon aus, dass Sie das erweiterte Filterverhalten für implementieren möchten`onGroupTicketCreated`. Für das `onGroupTicketCreated` Abonnement ist ein obligatorischer `group` Name als Argument erforderlich. Bei der Erstellung wird den Tickets automatisch ein `pending` Status zugewiesen. Sie können einen Abonnementfilter einrichten, um nur neu erstellte Tickets zu erhalten, die zu der angegebenen Gruppe gehören:

```
import { util, extensions } from '@aws-appsync/utils';

export function request(ctx) {
	// simplfy return null for the payload
	return { payload: null };
}

export function response(ctx) {
	const filter = { group: { eq: ctx.args.group }, status: { eq: 'pending' } };
	extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter));

	return null;
}
```

Wenn Daten mithilfe einer Mutation wie im folgenden Beispiel veröffentlicht werden:

```
mutation CreateTicket {
  createTicket(input: {priority: medium, severity: 2, group: "aws"}) {
    id
    priority
    severity
    status
    group
    createdAt
  }
}
```

Abonnierte Kunden warten darauf, dass die Daten automatisch weitergeleitet werden, WebSockets sobald ein Ticket mit der `createTicket` Mutation erstellt wird:

```
subscription OnGroup {
  onGroupTicketCreated(group: "aws") {
    category
    status
    severity
    priority
    id
    group
    createdAt
    content
  }
}
```

Clients können ohne Argumente abonniert werden, da die Filterlogik im AWS AppSync Service mit erweiterter Filterung implementiert ist, wodurch der Client-Code vereinfacht wird. Clients erhalten Daten nur, wenn die definierten Filterkriterien erfüllt sind.

## Definition erweiterter Filter für verschachtelte Schemafelder
<a name="aws-appsync-real-time-enhanced-filters-nested-schema-fields.title"></a>

Sie können die erweiterte Abonnementfilterung verwenden, um verschachtelte Schemafelder zu filtern. Angenommen, wir haben das Schema aus dem vorherigen Abschnitt geändert, um Standort- und Adresstypen einzubeziehen:

```
type Ticket {
	id: ID
	createdAt: AWSDateTime
	content: String
	severity: Int
	priority: Priority
	category: String
	group: String
	status: String
	location: ProblemLocation
}

type Mutation {
	createTicket(input: TicketInput): Ticket
}

type Query {
	getTicket(id: ID!): Ticket
}

type Subscription {
	onSpecialTicketCreated: Ticket @aws_subscribe(mutations: ["createTicket"])
	onGroupTicketCreated(group: String!): Ticket @aws_subscribe(mutations: ["createTicket"])
}

type ProblemLocation {
	address: Address
}

type Address {
	country: String
}

enum Priority {
	none
	lowest
	low
	medium
	high
	highest
}

input TicketInput {
	content: String
	severity: Int
	priority: Priority
	category: String
	group: String
	location: AWSJSON
```

Mit diesem Schema können Sie ein `.` Trennzeichen verwenden, um die Verschachtelung darzustellen. Im folgenden Beispiel wird eine Filterregel für ein verschachteltes Schemafeld unter hinzugefügt. `location.address.country` Das Abonnement wird ausgelöst, wenn die Adresse des Tickets wie folgt gesetzt `USA` ist:

```
import { util, extensions } from '@aws-appsync/utils';

export const request = (ctx) => ({ payload: null });

export function response(ctx) {
	const filter = {
		or: [
			{ severity: { ge: 7 }, priority: { in: ['high', 'medium'] } },
			{ category: { eq: 'security' }, group: { in: ['admin', 'operators'] } },
			{ 'location.address.country': { eq: 'USA' } },
		],
	};
	extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter));
	return null;
}
```

Steht im obigen Beispiel `location` für Verschachtelungsebene eins, `address` für Verschachtelungsebene zwei und `country` für Verschachtelungsebene drei, die alle durch das Trennzeichen getrennt sind. `.`

Sie können dieses Abonnement testen, indem Sie die folgende Mutation verwenden: `createTicket`

```
mutation CreateTicketInUSA {
  createTicket(input: {location: "{\"address\":{\"country\":\"USA\"}}"}) {
    category
    content
    createdAt
    group
    id
    location {
      address {
        country
      }
    }
    priority
    severity
    status
  }
}
```

## Definition erweiterter Filter vom Client aus
<a name="aws-appsync-real-time-enhanced-filtering-defining-from-client"></a>

Sie können die grundlegende Filterung in GraphQL mit [Abonnementargumenten](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html#using-subscription-arguments) verwenden. Der Client, der den Aufruf in der Abonnementabfrage durchführt, definiert die Werte der Argumente. Wenn erweiterte Filter in einem AWS AppSync Abonnement-Resolver mit der `extensions` Filterung aktiviert werden, haben die im Resolver definierten Backend-Filter Vorrang und Priorität.

Konfigurieren Sie dynamische, vom Client definierte erweiterte Filter mithilfe eines Arguments im Abonnement. `filter` Wenn Sie diese Filter konfigurieren, müssen Sie das GraphQL-Schema aktualisieren, um das neue Argument widerzuspiegeln:

```
...
type Subscription {
    onSpecialTicketCreated(filter: String): Ticket
        @aws_subscribe(mutations: ["createTicket"])
}
...
```

Der Client kann dann eine Abonnementabfrage wie im folgenden Beispiel senden:

```
subscription onSpecialTicketCreated($filter: String) {
     onSpecialTicketCreated(filter: $filter) {
        id
        group
        description
        priority
        severity
     }
 }
```

Sie können die Abfragevariable wie im folgenden Beispiel konfigurieren:

```
{"filter" : "{\"severity\":{\"le\":2}}"}
```

Das `util.transform.toSubscriptionFilter()` Resolver-Hilfsprogramm kann in der Vorlage für die Zuordnung von Abonnementantworten implementiert werden, um den im Abonnementargument definierten Filter für jeden Client anzuwenden:

```
import { util, extensions } from '@aws-appsync/utils';

export function request(ctx) {
	// simplfy return null for the payload
	return { payload: null };
}

export function response(ctx) {
	const filter = ctx.args.filter;
	extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter));
	return null;
}
```

Mit dieser Strategie können Kunden ihre eigenen Filter definieren, die eine erweiterte Filterlogik und zusätzliche Operatoren verwenden. Filter werden zugewiesen, wenn ein bestimmter Client die Abonnementabfrage in einer sicheren WebSocket Verbindung aufruft. Weitere Informationen zum Transformationsprogramm für erweiterte Filterung, einschließlich des Formats der Payload der `filter` Abfragevariablen, finden Sie unter Übersicht über [JavaScriptResolver](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html).

## Zusätzliche erweiterte Filtereinschränkungen
<a name="aws-appsync-real-time-enhanced-filtering-additional-restrictions"></a>

Im Folgenden sind mehrere Anwendungsfälle aufgeführt, in denen erweiterte Filter zusätzlichen Einschränkungen unterliegen:
+ Verbesserte Filter unterstützen keine Filterung für Objektlisten der obersten Ebene. In diesem Anwendungsfall werden veröffentlichte Daten aus der Mutation bei erweiterten Abonnements ignoriert.
+ AWS AppSync unterstützt bis zu fünf Verschachtelungsebenen. Filter für Schemafelder, die nach der Verschachtelungsebene fünf liegen, werden ignoriert. Nehmen Sie die unten stehende GraphQL-Antwort. Das `continent` Eingabefeld `venue.address.country.metadata.continent` ist zulässig, da es sich um ein Nest der Stufe 5 handelt. Da `venue.address.country.metadata.capital.financial` es `financial` sich jedoch um ein Nest der Stufe sechs handelt, funktioniert der Filter nicht:

  ```
  {
      "data": {
          "onCreateFilterEvent": {
              "venue": {
                  "address": {
                      "country": {
                          "metadata": {
                              "capital": {
                                  "financial": "New York"
                              },
                              "continent" : "North America"
                          }
                      },
                      "state": "WA"
                  },
                  "builtYear": 2023
              },
              "private": false,
          }
      }
  }
  ```

# WebSocket Verbindungen mithilfe von Filtern abbestellen in AWS AppSync
<a name="aws-appsync-real-time-invalidation"></a>

**Wichtig**  
Ab dem 13. März 2025 können Sie WebSockets mithilfe von AWS AppSync Events eine PubSub Echtzeit-API erstellen. Weitere Informationen finden Sie unter [Ereignisse veröffentlichen über WebSocket](https://docs.aws.amazon.com/appsync/latest/eventapi/publish-websocket.html) im *AWS AppSync Events Developer Guide*.

In AWS AppSync können Sie eine WebSocket Verbindung mit einem verbundenen Client auf der Grundlage einer bestimmten Filterlogik zwangsweise abbestellen und schließen (für ungültig erklären). Dies ist in autorisierungsbezogenen Szenarien nützlich, z. B. wenn Sie einen Benutzer aus einer Gruppe entfernen.

Die Invalidierung eines Abonnements erfolgt als Reaktion auf eine in einer Mutation definierte Nutzlast. Wir empfehlen, Mutationen, mit denen Abonnementverbindungen ungültig gemacht werden, als administrative Operationen in Ihrer API zu behandeln und die Berechtigungen entsprechend einzuschränken, indem Sie ihre Verwendung auf einen Admin-Benutzer, eine Gruppe oder einen Back-End-Dienst beschränken. Verwenden Sie beispielsweise Schemaautorisierungsrichtlinien wie `@aws_auth(cognito_groups: ["Administrators"])` oder. `@aws_iam` Weitere Informationen finden Sie unter [Zusätzliche Autorisierungsmodi verwenden](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html#using-additional-authorization-modes).

Invalidierungsfilter verwenden dieselbe Syntax und Logik wie [erweiterte Abonnementfilter](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-enhanced-filtering.html). Definieren Sie diese Filter mithilfe der folgenden Dienstprogramme:
+ `extensions.invalidateSubscriptions()`— Definiert im Response-Handler des GraphQL-Resolvers für eine Mutation.
+ `extensions.setSubscriptionInvalidationFilter()`— Definiert im Response-Handler des GraphQL-Resolvers für die mit der Mutation verknüpften Abonnements.

[Weitere Informationen zu Erweiterungen der Invalidierungsfilterung finden Sie JavaScript in der Übersicht über Resolver.](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html)

## Verwenden der Abonnement-Invalidierung
<a name="aws-appsync-real-time-invalidation-using-invalidations"></a>

Verwenden Sie das folgende GraphQL-Schema, um zu sehen AWS AppSync, wie die Invalidierung von Abonnements funktioniert:

```
type User {
  userId: ID!
  groupId: ID!
}
    
type Group {
  groupId: ID!
  name: String!
  members: [ID!]!
}

type GroupMessage {
  userId: ID!
  groupId: ID!
  message: String!
}

type Mutation {
    createGroupMessage(userId: ID!, groupId : ID!, message: String!): GroupMessage
    removeUserFromGroup(userId: ID!, groupId : ID!) : User @aws_iam
}

type Subscription {
    onGroupMessageCreated(userId: ID!, groupId : ID!): GroupMessage
        @aws_subscribe(mutations: ["createGroupMessage"])
}

type Query {
	none: String
}
```

Definieren Sie einen Invalidierungsfilter im `removeUserFromGroup` Mutationsauflösungscode:

```
import { extensions } from '@aws-appsync/utils';

export function request(ctx) {
	return { payload: null };
}

export function response(ctx) {
	const { userId, groupId } = ctx.args;
	extensions.invalidateSubscriptions({
		subscriptionField: 'onGroupMessageCreated',
		payload: { userId, groupId },
	});
	return { userId, groupId };
}
```

Wenn die Mutation aufgerufen wird, werden die im `payload` Objekt definierten Daten verwendet, um das in definierte Abonnement zu kündigen. `subscriptionField` In der Antwortzuordnungsvorlage des `onGroupMessageCreated` Abonnements ist auch ein Invalidierungsfilter definiert. 

Wenn die `extensions.invalidateSubscriptions()` Payload eine ID enthält, die der ID des IDs abonnierten Clients entspricht, wie im Filter definiert, wird das entsprechende Abonnement abgemeldet. Außerdem wird die Verbindung geschlossen. WebSocket Definieren Sie den Abonnement-Resolver-Code für das `onGroupMessageCreated` Abonnement:

```
import { util, extensions } from '@aws-appsync/utils';

export function request(ctx) {
	// simplfy return null for the payload
	return { payload: null };
}

export function response(ctx) {
	const filter = { groupId: { eq: ctx.args.groupId } };
	extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter));

	const invalidation = { groupId: { eq: ctx.args.groupId }, userId: { eq: ctx.args.userId } };
	extensions.setSubscriptionInvalidationFilter(util.transform.toSubscriptionFilter(invalidation));

	return null;
}
```

Beachten Sie, dass im Antworthandler für Abonnements sowohl Abonnementfilter als auch Invalidierungsfilter gleichzeitig definiert werden können.

Nehmen wir  beispielsweise an, dass Client A mithilfe der folgenden Abonnementanforderung einen neuen Benutzer mit der ID `user-1` für die Gruppe `group-1` mit der ID abonniert:

```
onGroupMessageCreated(userId : "user-1", groupId: :"group-1"){...}
```

AWS AppSync führt den Abonnement-Resolver aus, der Abonnement- und Invalidierungsfilter generiert, wie in der vorherigen `onGroupMessageCreated` Antwortzuordnungsvorlage definiert. Für Client A ermöglichen die Abonnementfilter das Senden von Daten nur an`group-1`, und die Invalidierungsfilter sind sowohl für als auch definiert. `user-1` `group-1`

Gehen Sie nun davon aus, dass Client B mithilfe der folgenden Abonnementanforderung `user-2` einen Benutzer mit der ID für eine Gruppe `group-2` mit der ID abonniert:

```
onGroupMessageCreated(userId : "user-2", groupId: :"group-2"){...}
```

AWS AppSync führt den Abonnement-Resolver aus, der Abonnement- und Invalidierungsfilter generiert. Für Client B ermöglichen die Abonnementfilter das Senden von Daten nur an`group-2`, und die Invalidierungsfilter sind sowohl für als auch definiert. `user-2` `group-2`

Gehen Sie als Nächstes davon aus, dass eine neue Gruppennachricht mit der ID mithilfe einer Mutationsanforderung wie im folgenden Beispiel erstellt `message-1` wird:

```
createGroupMessage(id: "message-1", groupId :
      "group-1", message: "test message"){...}
```

Abonnierte Clients, die den definierten Filtern entsprechen, erhalten automatisch die folgenden Datennutzdaten über: WebSockets

```
{
  "data": {
    "onGroupMessageCreated": {
      "id": "message-1",
      "groupId": "group-1",
      "message": "test message",
    }
  }
}
```

Client A erhält die Nachricht, weil die Filterkriterien mit dem definierten Abonnementfilter übereinstimmen. Client B empfängt die Nachricht jedoch nicht, da der Benutzer nicht Teil von ist`group-1`. Außerdem entspricht die Anfrage nicht dem Abonnementfilter, der im Abonnement-Resolver definiert ist.

Gehen Sie abschließend davon aus, dass `user-1` dies aus der `group-1` Verwendung der folgenden Mutationsanforderung entfernt wurde:

```
removeUserFromGroup(userId: "user-1", groupId : "group-1"){...}
```

Die Mutation leitet eine Abonnement-Invalidierung ein, wie sie in ihrem `extensions.invalidateSubscriptions()` Resolver-Antworthandlercode definiert ist. AWS AppSync meldet dann Client A ab und schließt seine Verbindung. WebSocket Client B ist davon nicht betroffen, da die in der Mutation definierte Payload für die Invalidierung nicht mit seinem Benutzer oder seiner Gruppe übereinstimmt.

Wenn eine Verbindung für AWS AppSync ungültig erklärt wird, erhält der Client eine Nachricht, in der bestätigt wird, dass er sich abgemeldet hat:

```
{
  "message": "Subscription complete."
}
```

## Verwendung von Kontextvariablen in Filtern für die Invalidierung von Abonnements
<a name="aws-appsync-real-time-invalidation-context"></a>

Wie bei erweiterten Abonnementfiltern können Sie die [`context`Variable](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference-js.html) in der Erweiterung für den Abonnement-Invalidierungsfilter verwenden, um auf bestimmte Daten zuzugreifen.

Beispielsweise ist es möglich, eine E-Mail-Adresse als Payload für die Invalidierung in der Mutation zu konfigurieren und sie dann mit dem E-Mail-Attribut oder dem Anspruch eines abonnierten Benutzers abzugleichen, der mit Amazon Cognito Cognito-Benutzerpools oder OpenID Connect autorisiert ist. Der im `extensions.setSubscriptionInvalidationFilter()` Abonnement-Invalidator definierte Invalidierungsfilter prüft, ob die durch die `extensions.invalidateSubscriptions()` Payload der Mutation festgelegte E-Mail-Adresse mit der E-Mail-Adresse übereinstimmt, die aus dem JWT-Token des Benutzers abgerufen wurde, wodurch die Ungültigerklärung eingeleitet wird. `context.identity.claims.email`

# Aufbau eines Echtzeit-Clients in WebSocket AWS AppSync
<a name="real-time-websocket-client"></a>

**Wichtig**  
Ab dem 13. März 2025 können Sie WebSockets mithilfe von AWS AppSync Events eine PubSub Echtzeit-API erstellen. Weitere Informationen finden Sie unter [Ereignisse veröffentlichen über WebSocket](https://docs.aws.amazon.com/appsync/latest/eventapi/publish-websocket.html) im *AWS AppSync Events Developer Guide*.

AWS AppSyncDer WebSocket Echtzeitclient ermöglicht GraphQL-Abonnements in einem mehrstufigen Prozess. Der Client stellt zunächst eine WebSocket Verbindung mit dem AWS AppSync Echtzeit-Endpunkt her, sendet eine Nachricht zur Verbindungsinitialisierung und wartet auf die Bestätigung. Nach erfolgreicher Verbindung registriert der Client Abonnements, indem er Startnachrichten mit eindeutigen IDs und GraphQL-Abfragen sendet. AWS AppSync bestätigt erfolgreiche Abonnements mit Bestätigungsnachrichten. Der Client wartet dann auf Abonnementereignisse, die durch entsprechende Mutationen ausgelöst werden. AWS AppSync Sendet regelmäßig Keep-Alive-Nachrichten, um die Verbindung aufrechtzuerhalten. Wenn der Vorgang abgeschlossen ist, hebt der Client die Registrierung der Abonnements auf, indem er Stoppnachrichten sendet. Dieses System unterstützt mehrere Abonnements über eine einzige WebSocket Verbindung und unterstützt verschiedene Autorisierungsmodi, darunter API-Schlüssel, Amazon Cognito Cognito-Benutzerpools, IAM und Lambda.

## WebSocket Client-Implementierung in Echtzeit für GraphQL-Abonnements
<a name="appsynclong-real-time-websocket-client-implementation-guide-for-graphql-subscriptions"></a>

Das folgende Sequenzdiagramm und die folgenden Schritte zeigen den Echtzeit-Abonnement-Workflow zwischen dem WebSocket Client, dem HTTP-Client und AWS AppSync.

![\[Sequence diagram showing WebSocket client, AppSync endpoints, and HTTP client interactions for real-time subscriptions.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/realtime-client-flow.png)


1. Der Client stellt eine WebSocket Verbindung mit dem AWS AppSync Echtzeit-Endpunkt her. Bei einem Netzwerkfehler sollte der Client einen exponentiellen Backoff-Jitter ausführen. Weitere Informationen finden Sie unter [Exponentieller Backoff und Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) im Architektur-Blog. AWS 

1. (Optional) Nach dem erfolgreichen WebSocket Verbindungsaufbau sendet der Client eine Nachricht. `connection_init`

1. Wenn `connection_init` gesendet, wartet der Client auf eine `connection_ack` Nachricht von AWS AppSync. Diese Nachricht enthält einen `connectionTimeoutMs` Parameter, der die maximale Wartezeit in Millisekunden für eine `"ka"` (Keep-Alive-) Nachricht angibt.

1. AWS AppSync sendet regelmäßig Nachrichten. `"ka"` Der Client verfolgt die Zeit, zu der er jede `"ka"` Nachricht empfangen hat. Wenn der Client innerhalb von `connectionTimeoutMs` Millisekunden keine `"ka"` Nachricht empfängt, sollte der Client die Verbindung schließen.

1. Der Client registriert das Abonnement, indem er eine `start`-Abonnementnachricht sendet. Eine einzelne WebSocket Verbindung unterstützt mehrere Abonnements, auch wenn sie sich in unterschiedlichen Autorisierungsmodi befinden.

1. Der Client wartet darauf AWS AppSync , dass `start_ack` Nachrichten gesendet werden, um erfolgreiche Abonnements zu bestätigen. Wenn ein Fehler auftritt, wird eine `"type": "error"` Meldung AWS AppSync zurückgegeben.

1. Der Client wartet auf Abonnementereignisse, die gesendet werden, nachdem eine entsprechende Mutation aufgerufen wurde. Abfragen und Mutationen werden normalerweise `https://` an den AWS AppSync GraphQL-Endpunkt gesendet. Abonnements werden mithilfe von secure WebSocket (`wss://`) über den AWS AppSync Echtzeit-Endpunkt abgewickelt.

1. Der Client hebt die Registrierung des Abonnements auf, indem er eine `stop`-Abonnementnachricht sendet.

1. Nachdem der Client die Registrierung aller Abonnements aufgehoben und überprüft hat, dass keine Nachrichten über das übertragen werden WebSocket, kann er die WebSocket Verbindung trennen.

## Handshake-Details zum Herstellen der Verbindung WebSocket
<a name="handshake-details-to-establish-the-websocket-connection"></a>

Um eine Verbindung herzustellen und einen erfolgreichen Handshake mit zu initiieren AWS AppSync, benötigt ein WebSocket Client Folgendes:
+ Der AWS AppSync Echtzeit-Endpunkt
+ Header — Enthalten Informationen, die für den AWS AppSync Endpunkt und die Autorisierung relevant sind. AWS AppSync unterstützt die folgenden drei Methoden zur Bereitstellung von Headern: 
  + Header per Abfragezeichenfolge
    + Die Header-Informationen sind als Base64-Zeichenfolge codiert, die von einem stringifizierten JSON-Objekt abgeleitet wird. Dieses JSON-Objekt enthält Details, die für den Endpunkt und die AWS AppSync Autorisierung relevant sind. Der Inhalt des JSON-Objekts variiert je nach Autorisierungsmodus.
  + Header über `Sec-WebSocket-Protocol`
    + Eine Base64URL-kodierte Zeichenfolge aus dem stringifizierten JSON-Objekt, die Informationen enthält, die für den AWS AppSync Endpunkt und die Autorisierung relevant sind, wird als Protokoll im Header übergeben. `Sec-WebSocket-Protocol` Der Inhalt des JSON-Objekts variiert je nach Autorisierungsmodus.
  + Header über Standard-HTTP-Header:
    + Header können als Standard-HTTP-Header in der Verbindungsanforderung übergeben werden, ähnlich wie Header für GraphQL-Abfragen und -Mutationen an übergeben werden. AWS AppSync Die Übergabe von Headern über Standard-HTTP-Header wird jedoch für private API-Verbindungsanfragen nicht unterstützt.
+  `payload`— Base64-kodierte Zeichenfolge von. `payload` Payload wird nur benötigt, wenn Header mithilfe einer Abfragezeichenfolge bereitgestellt werden

Mit diesen Anforderungen kann ein WebSocket Client eine Verbindung zu der URL herstellen, die den Echtzeit-Endpunkt mit der Abfragezeichenfolge enthält, die `graphql-ws` WebSocket als Protokoll verwendet wird.

### Erkennung des -Echtzeitendpunkts über den -GraphQL-Endpunkt
<a name="discovering-the-appsync-real-time-endpoint-from-the-appsync-graphql-endpoint"></a>

Der AWS AppSync GraphQL-Endpunkt und der AWS AppSync Echtzeit-Endpunkt unterscheiden sich geringfügig in Protokoll und Domäne. Sie können den GraphQL-Endpunkt mit dem Befehl AWS Command Line Interface `aws appsync get-graphql-api` (AWS CLI) abrufen.

****AWS AppSync GraphQL-Endpunkt:****  
 `https://example1234567890000.appsync-api.us-east-1.amazonaws.com/graphql`

****AWS AppSync Echtzeit-Endpunkt:****  
 `wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql`

Anwendungen können über einen beliebigen HTTP-Client für Abfragen und Mutationen eine Verbindung zum AWS AppSync GraphQL-Endpunkt (`https://`) herstellen. Anwendungen können sich mit einem beliebigen WebSocket Client für Abonnements mit dem AWS AppSync Echtzeit-Endpunkt (`wss://`) verbinden.

Mit benutzerdefinierten Domainnamen können Sie über eine einzige Domain mit beiden Endpunkten interagieren. Wenn Sie beispielsweise `api.example.com` als Ihre benutzerdefinierte Domain konfigurieren, können Sie mit Ihren GraphQL- und Echtzeit-Endpunkten über diese interagieren: URLs

**AWS AppSync GraphQL-Endpunkt für benutzerdefinierte Domänen:**  
`https://api.example.com/graphql`

**AWS AppSync Echtzeit-Endpunkt für benutzerdefinierte Domänen:**  
`wss://api.example.com/graphql/realtime`

## Das Format der Header-Parameter basiert auf dem AWS AppSync API-Autorisierungsmodus
<a name="header-parameter-format-based-on-appsync-api-authorization-mode"></a>

Das Format des in der Verbindungsabfragezeichenfolge verwendeten `header` Objekts hängt vom AWS AppSync API-Autorisierungsmodus ab. Das `host` Feld im Objekt bezieht sich auf den AWS AppSync GraphQL-Endpunkt, der verwendet wird, um die Verbindung zu validieren, auch wenn der `wss://` Aufruf gegen den Echtzeit-Endpunkt erfolgt. Um den Handshake zu initiieren und die autorisierte Verbindung herzustellen, sollte es sich bei `payload` um ein leeres JSON-Objekt handeln. Payload wird nur benötigt, wenn Header per Abfragestring übergeben werden.

In den folgenden Abschnitten werden die Header-Formate für jeden Autorisierungsmodus veranschaulicht.

### API-Schlüssel
<a name="api-key"></a>

#### Kopfzeile des API-Schlüssels
<a name="api-key-list"></a>

**Inhalt der Kopfzeile**
+  `"host": <string>`: Der Host für den AWS AppSync GraphQL-Endpunkt oder Ihren benutzerdefinierten Domainnamen.
+  `"x-api-key": <string>`: Der für die API konfigurierte AWS AppSync API-Schlüssel.

**Beispiel**

```
{
    "host":"example1234567890000.appsync-api.us-east-1.amazonaws.com",
    "x-api-key":"da2-12345678901234567890123456"
}
```

**Header per Abfragezeichenfolge**

Zunächst wird ein JSON-Objekt, das das `host` und `x-api-key` das enthält, in eine Zeichenfolge umgewandelt. Als Nächstes wird diese Zeichenfolge mithilfe der Base64-Kodierung codiert. Die resultierende Base64-kodierte Zeichenfolge wird als Abfrageparameter mit dem Namen der WebSocket URL hinzugefügt`header`, um die Verbindung mit dem Echtzeit-Endpunkt herzustellen. AWS AppSync Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql?header=eyJob3N0IjoiZXhhbXBsZTEyMzQ1Njc4OTAwMDAuYXBwc3luYy1hcGkudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20iLCJ4LWFtei1kYXRlIjoiMjAyMDA0MDFUMDAxMDEwWiIsIngtYXBpLWtleSI6ImRhMi16NHc0NHZoczV6Z2MzZHRqNXNranJsbGxqaSJ9&payload=e30=
```

Es ist wichtig zu beachten, dass neben dem Base64-codierten Header-Objekt auch ein leeres JSON-Objekt \$1\$1 Base64-codiert und als separater Abfrageparameter in der URL enthalten ist. `payload` WebSocket

**Header über `Sec-WebSocket-Protocol`**

Ein JSON-Objekt, das das `host` und das enthält, `x-api-key` wird in eine Zeichenfolge konvertiert und dann mit der Base64URL-Codierung codiert. Der resultierenden Base64URL-codierten Zeichenfolge wird ein Präfix vorangestellt. `header-` Diese Zeichenfolge mit Präfix wird dann zusätzlich zum `Sec-WebSocket-Protocol` Header als neues Unterprotokoll verwendet, wenn die Verbindung mit dem `graphql-ws` Echtzeit-Endpunkt hergestellt wird. WebSocket AWS AppSync 

Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Der `Sec-WebSocket-Protocol` Header enthält den folgenden Wert:

```
"sec-websocket-protocol" : ["graphql-ws", "header-ewogICAgImhvc3QiOiJleGFtcGxlMTIzNDU2Nzg5MDAwMC5hcHBzeW5jLWFwaS51cy1lYXN0LTEuYW1hem9uYXdzLmNvbSIsCiAgICAieC1hcGkta2V5IjoiZGEyLTEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Igp9"]
```

**Header über Standard-HTTP-Header**

Bei dieser Methode werden die Host- und API-Schlüsselinformationen mithilfe von Standard-HTTP-Headern übertragen, wenn die WebSocket Verbindung mit dem AWS AppSync Echtzeit-Endpunkt hergestellt wird. Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Die Anforderungsheader würden Folgendes beinhalten:

```
"sec-websocket-protocol" : ["graphql-ws"]
"host":"example1234567890000.appsync-api.us-east-1.amazonaws.com",
"x-api-key":"da2-12345678901234567890123456"
```

### Amazon Cognito-Benutzerpools und OpenID Connect (OIDC)
<a name="amazon-cognito-user-pools-and-openid-connect-oidc"></a>

#### Amazon Cognito und OIDC-Header
<a name="amazon-cognito-user-pools-and-openid-connect-oidc-list"></a>

Inhalt des Headers:
+  `"Authorization": <string>`: Ein JWT-ID-Token. Der Header kann ein [Bearer-Schema](https://datatracker.ietf.org/doc/html/rfc6750#section-2.1) verwenden.
+  `"host": <string>`: Der Host für den AWS AppSync GraphQL-Endpunkt oder Ihren benutzerdefinierten Domainnamen.

Beispiel:

```
{
    "Authorization":"eyEXAMPLEiJjbG5xb3A5eW5MK09QYXIrMTJHWEFLSXBieU5WNHhsQjEXAMPLEnM2WldvPSIsImFsZyI6IlEXAMPLEn0.eyEXAMPLEiJhNmNmMjcwNy0xNjgxLTQ1NDItOWYxOC1lNjY0MTg2NjlkMzYiLCJldmVudF9pZCI6ImVkMzM5MmNkLWNjYTMtNGM2OC1hNDYyLTJlZGI3ZTNmY2FjZiIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoiYXdzLmNvZ25pdG8uc2lnbmluLnVzZXIuYWRtaW4iLCJhdXRoX3RpbWUiOjE1Njk0NTc3MTgsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5hcC1zb3V0aGVhc3QtMi5hbWF6b25hd3MuY29tXC9hcC1zb3V0aGVhc3QtMl83OHY0SVZibVAiLCJleHAiOjE1Njk0NjEzMjAsImlhdCI6MTU2OTQ1NzcyMCwianRpIjoiNTgzZjhmYmMtMzk2MS00YzA4LWJhZTAtYzQyY2IxMTM5NDY5IiwiY2xpZW50X2lkIjoiM3FlajVlMXZmMzd1N3RoZWw0dG91dDJkMWwiLCJ1c2VybmFtZSI6ImVsb3EXAMPLEn0.B4EXAMPLEFNpJ6ikVp7e6DRee95V6Qi-zEE2DJH7sHOl2zxYi7f-SmEGoh2AD8emxQRYajByz-rE4Jh0QOymN2Ys-ZIkMpVBTPgu-TMWDyOHhDUmUj2OP82yeZ3wlZAtr_gM4LzjXUXmI_K2yGjuXfXTaa1mvQEBG0mQfVd7SfwXB-jcv4RYVi6j25qgow9Ew52ufurPqaK-3WAKG32KpV8J4-Wejq8t0c-yA7sb8EnB551b7TU93uKRiVVK3E55Nk5ADPoam_WYE45i3s5qVAP_-InW75NUoOCGTsS8YWMfb6ecHYJ-1j-bzA27zaT9VjctXn9byNFZmEXAMPLExw",
    "host":"example1234567890000.appsync-api.us-east-1.amazonaws.com"
}
```

**Header per Abfragezeichenfolge**

Zunächst wird ein JSON-Objekt, das das `host` und `Authorization` das enthält, in eine Zeichenfolge umgewandelt. Als Nächstes wird diese Zeichenfolge mithilfe der Base64-Kodierung codiert. Die resultierende Base64-kodierte Zeichenfolge wird als Abfrageparameter mit dem Namen der WebSocket URL hinzugefügt`header`, um die Verbindung mit dem Echtzeit-Endpunkt herzustellen. AWS AppSync Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql?header=eyJBdXRob3JpemF0aW9uIjoiZXlKcmFXUWlPaUpqYkc1eGIzQTVlVzVNSzA5UVlYSXJNVEpIV0VGTFNYQmllVTVXTkhoc1FqaFBWVzlZTW5NMldsZHZQU0lzSW1Gc1p5STZJbEpUTWpVMkluMC5leUp6ZFdJaU9pSmhObU5tTWpjd055MHhOamd4TFRRMU5ESXRPV1l4T0MxbE5qWTBNVGcyTmpsa016WWlMQ0psZG1WdWRGOXBaQ0k2SW1Wa016TTVNbU5rTFdOallUTXROR00yT0MxaE5EWXlMVEpsWkdJM1pUTm1ZMkZqWmlJc0luUnZhMlZ1WDNWelpTSTZJbUZqWTJWemN5SXNJbk5qYjNCbElqb2lZWGR6TG1OdloyNXBkRzh1YzJsbmJtbHVMblZ6WlhJdVlXUnRhVzRpTENKaGRYUm9YM1JwYldVaU9qRTFOamswTlRjM01UZ3NJbWx6Y3lJNkltaDBkSEJ6T2x3dlhDOWpiMmR1YVhSdkxXbGtjQzVoY0MxemIzVjBhR1ZoYzNRdE1pNWhiV0Y2YjI1aGQzTXVZMjl0WEM5aGNDMXpiM1YwYUdWaGMzUXRNbDgzT0hZMFNWWmliVkFpTENKbGVIQWlPakUxTmprME5qRXpNakFzSW1saGRDSTZNVFUyT1RRMU56Y3lNQ3dpYW5ScElqb2lOVGd6WmpobVltTXRNemsyTVMwMFl6QTRMV0poWlRBdFl6UXlZMkl4TVRNNU5EWTVJaXdpWTJ4cFpXNTBYMmxrSWpvaU0zRmxhalZsTVhabU16ZDFOM1JvWld3MGRHOTFkREprTVd3aUxDSjFjMlZ5Ym1GdFpTSTZJbVZzYjNKNllXWmxJbjAuQjRjZEp0aDNLRk5wSjZpa1ZwN2U2RFJlZTk1VjZRaS16RUUyREpIN3NIT2wyenhZaTdmLVNtRUdvaDJBRDhlbXhRUllhakJ5ei1yRTRKaDBRT3ltTjJZcy1aSWtNcFZCVFBndS1UTVdEeU9IaERVbVVqMk9QODJ5ZVozd2xaQXRyX2dNNEx6alhVWG1JX0syeUdqdVhmWFRhYTFtdlFFQkcwbVFmVmQ3U2Z3WEItamN2NFJZVmk2ajI1cWdvdzlFdzUydWZ1clBxYUstM1dBS0czMktwVjhKNC1XZWpxOHQwYy15QTdzYjhFbkI1NTFiN1RVOTN1S1JpVlZLM0U1NU5rNUFEUG9hbV9XWUU0NWkzczVxVkFQXy1Jblc3NU5Vb09DR1RzUzhZV01mYjZlY0hZSi0xai1iekEyN3phVDlWamN0WG45YnlORlptS0xwQTJMY3h3IiwiaG9zdCI6ImV4YW1wbGUxMjM0NTY3ODkwMDAwLmFwcHN5bmMtYXBpLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tIn0=&payload=e30=
```

Es ist wichtig zu beachten, dass neben dem Base64-codierten Header-Objekt auch ein leeres JSON-Objekt \$1\$1 Base64-codiert und als separater Abfrageparameter in der URL enthalten ist. `payload` WebSocket

**Header über `Sec-WebSocket-Protocol`**

Ein JSON-Objekt, das das `host` und das enthält, `Authorization` wird in eine Zeichenfolge konvertiert und dann mit der Base64URL-Codierung codiert. Der resultierenden Base64URL-codierten Zeichenfolge wird ein Präfix vorangestellt. `header-` Diese Zeichenfolge mit Präfix wird dann zusätzlich zum `Sec-WebSocket-Protocol` Header als neues Unterprotokoll verwendet, wenn die Verbindung mit dem `graphql-ws` Echtzeit-Endpunkt hergestellt wird. WebSocket AWS AppSync 

Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Der `Sec-WebSocket-Protocol` Header enthält den folgenden Wert:

```
"sec-websocket-protocol" : ["graphql-ws", "header-ewogICAgImhvc3QiOiJleGFtcGxlMTIzNDU2Nzg5MDAwMC5hcHBzeW5jLWFwaS51cy1lYXN0LTEuYW1hem9uYXdzLmNvbSIsCiAgICAieC1hcGkta2V5IjoiZGEyLTEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Igp9"]
```

**Header über Standard-HTTP-Header**

Bei dieser Methode werden die Host- und Autorisierungsinformationen beim WebSocket Verbindungsaufbau mit dem Echtzeit-Endpunkt mithilfe von Standard-HTTP-Headern übertragen. AWS AppSync Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Die Anforderungsheader würden Folgendes beinhalten:

```
"sec-websocket-protocol" : ["graphql-ws"]
"Authorization":"eyEXAMPLEiJjbG5xb3A5eW5MK09QYXIrMTJHWEFLSXBieU5WNHhsQjEXAMPLEnM2WldvPSIsImFsZyI6IlEXAMPLEn0.eyEXAMPLEiJhNmNmMjcwNy0xNjgxLTQ1NDItOWYxOC1lNjY0MTg2NjlkMzYiLCJldmVudF9pZCI6ImVkMzM5MmNkLWNjYTMtNGM2OC1hNDYyLTJlZGI3ZTNmY2FjZiIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoiYXdzLmNvZ25pdG8uc2lnbmluLnVzZXIuYWRtaW4iLCJhdXRoX3RpbWUiOjE1Njk0NTc3MTgsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5hcC1zb3V0aGVhc3QtMi5hbWF6b25hd3MuY29tXC9hcC1zb3V0aGVhc3QtMl83OHY0SVZibVAiLCJleHAiOjE1Njk0NjEzMjAsImlhdCI6MTU2OTQ1NzcyMCwianRpIjoiNTgzZjhmYmMtMzk2MS00YzA4LWJhZTAtYzQyY2IxMTM5NDY5IiwiY2xpZW50X2lkIjoiM3FlajVlMXZmMzd1N3RoZWw0dG91dDJkMWwiLCJ1c2VybmFtZSI6ImVsb3EXAMPLEn0.B4EXAMPLEFNpJ6ikVp7e6DRee95V6Qi-zEE2DJH7sHOl2zxYi7f-SmEGoh2AD8emxQRYajByz-rE4Jh0QOymN2Ys-ZIkMpVBTPgu-TMWDyOHhDUmUj2OP82yeZ3wlZAtr_gM4LzjXUXmI_K2yGjuXfXTaa1mvQEBG0mQfVd7SfwXB-jcv4RYVi6j25qgow9Ew52ufurPqaK-3WAKG32KpV8J4-Wejq8t0c-yA7sb8EnB551b7TU93uKRiVVK3E55Nk5ADPoam_WYE45i3s5qVAP_-InW75NUoOCGTsS8YWMfb6ecHYJ-1j-bzA27zaT9VjctXn9byNFZmEXAMPLExw",
"host":"example1234567890000.appsync-api.us-east-1.amazonaws.com"
```

### IAM
<a name="iam"></a>

#### IAM-Header
<a name="iam-list"></a>

**Inhalt der Kopfzeile**
+  `"accept": "application/json, text/javascript"`: Ein konstanter `<string>`-Parameter.
+  `"content-encoding": "amz-1.0"`: Ein konstanter `<string>`-Parameter.
+  `"content-type": "application/json; charset=UTF-8"`: Ein konstanter `<string>`-Parameter.
+  `"host": <string>`: Dies ist der Host für den AWS AppSync GraphQL-Endpunkt.
  + `"x-amz-date": <string>`: Der Zeitstempel muss in UTC und im folgenden ISO 8601-Format sein: YYYYMMDD'T'HHMMSS'Z'. Ein gültiger Zeitstempel ist beispielsweise 20150830T123600Z. Der Zeitstempel darf keine Millisekunden enthalten. [Weitere Informationen finden Sie unter Umgang mit Daten in Signature Version 4 in der. *Allgemeine AWS-Referenz*](https://docs.aws.amazon.com/general/latest/gr/sigv4-date-handling.html)
  +  `"X-Amz-Security-Token": <string>`: Das AWS Sitzungstoken, das bei der Verwendung temporärer Sicherheitsanmeldedaten erforderlich ist. Weitere Informationen finden Sie unter [Verwenden von temporären Anmeldeinformationen mit AWS -Ressourcen ](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_use-resources.html) im *IAM-Benutzerhandbuch*.
  +  `"Authorization": <string>`: Signaturinformationen der Version 4 (Sigv4) für den AWS AppSync Endpunkt. Weitere Informationen zum Signiervorgang finden Sie unter [Aufgabe 4: Hinzufügen der Signatur zur HTTP-Anfrage](https://docs.aws.amazon.com/general/latest/gr/sigv4-add-signature-to-request.html) in der *Allgemeine AWS-Referenz*.

Die Sigv4-Signatur-HTTP-Anforderung enthält eine kanonische URL. Dies ist der AWS AppSync -GraphQL-Endpunkt, dem `/connect` angefügt wurde. Die AWS Service-Endpunkt-Region ist dieselbe Region, in der Sie die AWS AppSync API verwenden, und der Dienstname ist „appsync“. Die HTTP-Anforderung für die Signatur ist wie folgt:

```
{
  url: "https://example1234567890000.appsync-api.us-east-1.amazonaws.com/graphql/connect",
  data: "{}",
  method: "POST",
  headers: {
    "accept": "application/json, text/javascript",
    "content-encoding": "amz-1.0",
    "content-type": "application/json; charset=UTF-8",
  }
}
```

**Beispiel**

```
{
  "accept": "application/json, text/javascript",
  "content-encoding": "amz-1.0",
  "content-type": "application/json; charset=UTF-8",
  "host": "example1234567890000.appsync-api.us-east-1.amazonaws.com",
  "x-amz-date": "20200401T001010Z",
  "X-Amz-Security-Token": "AgEXAMPLEZ2luX2VjEAoaDmFwLXNvdXRoZWFEXAMPLEcwRQIgAh97Cljq7wOPL8KsxP3YtDuyc/9hAj8PhJ7Fvf38SgoCIQDhJEXAMPLEPspioOztj++pEagWCveZUjKEn0zyUhBEXAMPLEjj//////////8BEXAMPLExODk2NDgyNzg1NSIMo1mWnpESWUoYw4BkKqEFSrm3DXuL8w+ZbVc4JKjDP4vUCKNR6Le9C9pZp9PsW0NoFy3vLBUdAXEXAMPLEOVG8feXfiEEA+1khgFK/wEtwR+9zF7NaMMMse07wN2gG2tH0eKMEXAMPLEQX+sMbytQo8iepP9PZOzlZsSFb/dP5Q8hk6YEXAMPLEYcKZsTkDAq2uKFQ8mYUVA9EtQnNRiFLEY83aKvG/tqLWNnGlSNVx7SMcfovkFDqQamm+88y1OwwAEYK7qcoceX6Z7GGcaYuIfGpaX2MCCELeQvZ+8WxEgOnIfz7GYvsYNjLZSaRnV4G+ILY1F0QNW64S9Nvj+BwDg3ht2CrNvpwjVYlj9U3nmxE0UG5ne83LL5hhqMpm25kmL7enVgw2kQzmU2id4IKu0C/WaoDRuO2F5zE63vJbxN8AYs7338+4B4HBb6BZ6OUgg96Q15RA41/gIqxaVPxyTpDfTU5GfSLxocdYeniqqpFMtZG2n9d0u7GsQNcFkNcG3qDZm4tDo8tZbuym0a2VcF2E5hFEgXBa+XLJCfXi/77OqAEjP0x7Qdk3B43p8KG/BaioP5RsV8zBGvH1zAgyPha2rN70/tT13yrmPd5QYEfwzexjKrV4mWIuRg8NTHYSZJUaeyCwTom80VFUJXG+GYTUyv5W22aBcnoRGiCiKEYTLOkgXecdKFTHmcIAejQ9Welr0a196Kq87w5KNMCkcCGFnwBNFLmfnbpNqT6rUBxxs3X5ntX9d8HVtSYINTsGXXMZCJ7fnbWajhg/aox0FtHX21eF6qIGT8j1z+l2opU+ggwUgkhUUgCH2TfqBj+MLMVVvpgqJsPKt582caFKArIFIvO+9QupxLnEH2hz04TMTfnU6bQC6z1buVe7h+tOLnh1YPFsLQ88anib/7TTC8k9DsBTq0ASe8R2GbSEsmO9qbbMwgEaYUhOKtGeyQsSJdhSk6XxXThrWL9EnwBCXDkICMqdntAxyyM9nWsZ4bL9JHqExgWUmfWChzPFAqn3F4y896UqHTZxlq3WGypn5HHcem2Hqf3IVxKH1inhqdVtkryEiTWrI7ZdjbqnqRbl+WgtPtKOOweDlCaRs3R2qXcbNgVhleMk4IWnF8D1695AenU1LwHjOJLkCjxgNFiWAFEPH9aEXAMPLExA==",
  "Authorization": "AWS4-HMAC-SHA256 Credential=XXXXXXXXXXXXXXXXXXX/20200401/us-east-1/appsync/aws4_request, SignedHeaders=accept;content-encoding;content-type;host;x-amz-date;x-amz-security-token, Signature=83EXAMPLEbcc1fe3ee69f75cd5ebbf4cb4f150e4f99cec869f149c5EXAMPLEdc"
}
```

**Header per Abfragezeichenfolge**

Zunächst wird ein JSON-Objekt, das den `host` (AWS AppSync GraphQL-Endpunkt) und die anderen Autorisierungsheader enthält, in eine Zeichenfolge umgewandelt. Als Nächstes wird diese Zeichenfolge mithilfe der Base64-Kodierung codiert. Die resultierende Base64-kodierte Zeichenfolge wird der WebSocket URL als Abfrageparameter mit dem Namen hinzugefügt. `header` Die resultierende Anforderungs-URL hat das folgende Format:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql?header=eyJBdXRob3JpemF0aW9uIjoiZXlKcmFXUWlPaUpqYkc1eGIzQTVlVzVNSzA5UVlYSXJNVEpIV0VGTFNYQmllVTVXTkhoc1FqaFBWVzlZTW5NMldsZHZQU0lzSW1Gc1p5STZJbEpUTWpVMkluMC5leUp6ZFdJaU9pSmhObU5tTWpjd055MHhOamd4TFRRMU5ESXRPV1l4T0MxbE5qWTBNVGcyTmpsa016WWlMQ0psZG1WdWRGOXBaQ0k2SW1Wa016TTVNbU5rTFdOallUTXROR00yT0MxaE5EWXlMVEpsWkdJM1pUTm1ZMkZqWmlJc0luUnZhMlZ1WDNWelpTSTZJbUZqWTJWemN5SXNJbk5qYjNCbElqb2lZWGR6TG1OdloyNXBkRzh1YzJsbmJtbHVMblZ6WlhJdVlXUnRhVzRpTENKaGRYUm9YM1JwYldVaU9qRTFOamswTlRjM01UZ3NJbWx6Y3lJNkltaDBkSEJ6T2x3dlhDOWpiMmR1YVhSdkxXbGtjQzVoY0MxemIzVjBhR1ZoYzNRdE1pNWhiV0Y2YjI1aGQzTXVZMjl0WEM5aGNDMXpiM1YwYUdWaGMzUXRNbDgzT0hZMFNWWmliVkFpTENKbGVIQWlPakUxTmprME5qRXpNakFzSW1saGRDSTZNVFUyT1RRMU56Y3lNQ3dpYW5ScElqb2lOVGd6WmpobVltTXRNemsyTVMwMFl6QTRMV0poWlRBdFl6UXlZMkl4TVRNNU5EWTVJaXdpWTJ4cFpXNTBYMmxrSWpvaU0zRmxhalZsTVhabU16ZDFOM1JvWld3MGRHOTFkREprTVd3aUxDSjFjMlZ5Ym1GdFpTSTZJbVZzYjNKNllXWmxJbjAuQjRjZEp0aDNLRk5wSjZpa1ZwN2U2RFJlZTk1VjZRaS16RUUyREpIN3NIT2wyenhZaTdmLVNtRUdvaDJBRDhlbXhRUllhakJ5ei1yRTRKaDBRT3ltTjJZcy1aSWtNcFZCVFBndS1UTVdEeU9IaERVbVVqMk9QODJ5ZVozd2xaQXRyX2dNNEx6alhVWG1JX0syeUdqdVhmWFRhYTFtdlFFQkcwbVFmVmQ3U2Z3WEItamN2NFJZVmk2ajI1cWdvdzlFdzUydWZ1clBxYUstM1dBS0czMktwVjhKNC1XZWpxOHQwYy15QTdzYjhFbkI1NTFiN1RVOTN1S1JpVlZLM0U1NU5rNUFEUG9hbV9XWUU0NWkzczVxVkFQXy1Jblc3NU5Vb09DR1RzUzhZV01mYjZlY0hZSi0xai1iekEyN3phVDlWamN0WG45YnlORlptS0xwQTJMY3h3IiwiaG9zdCI6ImV4YW1wbGUxMjM0NTY3ODkwMDAwLmFwcHN5bmMtYXBpLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tIn0=&payload=e30=
```

Es ist wichtig zu beachten, dass neben dem Base64-codierten Header-Objekt auch ein leeres JSON-Objekt \$1\$1 Base64-codiert und als separater Abfrageparameter in der URL enthalten ist. `payload` WebSocket

**Header über `Sec-WebSocket-Protocol`**

Ein JSON-Objekt, das die `host` und die anderen Autorisierungsheader enthält, wird in eine Zeichenfolge konvertiert und dann mit der Base64URL-Kodierung codiert. Der resultierenden Base64URL-codierten Zeichenfolge wird ein Präfix vorangestellt. `header-` Diese Zeichenfolge mit Präfix wird dann zusätzlich zum `Sec-WebSocket-Protocol` Header als neues Unterprotokoll verwendet, wenn die Verbindung mit dem `graphql-ws` Echtzeit-Endpunkt hergestellt wird. WebSocket AWS AppSync 

Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Der `Sec-WebSocket-Protocol` Header enthält den folgenden Wert:

```
"sec-websocket-protocol" : ["graphql-ws", "header-ew0KICAiYWNjZXB0IjogImFwcGxpY2F0aW9uL2pzb24sIHRleHQvamF2YXNjcmlwdCIsDQogICJjb250ZW50LWVuY29kaW5nIjogImFtei0xLjAiLA0KICAiY29udGVudC10eXBlIjogImFwcGxpY2F0aW9uL2pzb247IGNoYXJzZXQ9VVRGLTgiLA0KICAiaG9zdCI6ICJleGFtcGxlMTIzNDU2Nzg5MDAwMC5hcHBzeW5jLWFwaS51cy1lYXN0LTEuYW1hem9uYXdzLmNvbSIsDQogICJ4LWFtei1kYXRlIjogIjIwMjAwNDAxVDAwMTAxMFoiLA0KICAiWC1BbXotU2VjdXJpdHktVG9rZW4iOiAiQWdFWEFNUExFWjJsdVgyVmpFQW9hRG1Gd0xYTnZkWFJvWldGRVhBTVBMRWN3UlFJZ0FoOTdDbGpxN3dPUEw4S3N4UDNZdER1eWMvOWhBajhQaEo3RnZmMzhTZ29DSVFEaEpFWEFNUExFUHNwaW9PenRqKytwRWFnV0N2ZVpVaktFbjB6eVVoQkVYQU1QTEVqai8vLy8vLy8vLy84QkVYQU1QTEV4T0RrMk5EZ3lOemcxTlNJTW8xbVducEVTV1VvWXc0QmtLcUVGU3JtM0RYdUw4dytaYlZjNEpLakRQNHZVQ0tOUjZMZTlDOXBacDlQc1cwTm9GeTN2TEJVZEFYRVhBTVBMRU9WRzhmZVhmaUVFQSsxa2hnRksvd0V0d1IrOXpGN05hTU1Nc2UwN3dOMmdHMnRIMGVLTUVYQU1QTEVRWCtzTWJ5dFFvOGllcFA5UFpPemxac1NGYi9kUDVROGhrNllFWEFNUExFWWNLWnNUa0RBcTJ1S0ZROG1ZVVZBOUV0UW5OUmlGTEVZODNhS3ZHL3RxTFdObkdsU05WeDdTTWNmb3ZrRkRxUWFtbSs4OHkxT3d3QUVZSzdxY29jZVg2WjdHR2NhWXVJZkdwYVgyTUNDRUxlUXZaKzhXeEVnT25JZno3R1l2c1lOakxaU2FSblY0RytJTFkxRjBRTlc2NFM5TnZqK0J3RGczaHQyQ3JOdnB3alZZbGo5VTNubXhFMFVHNW5lODNMTDVoaHFNcG0yNWttTDdlblZndzJrUXptVTJpZDRJS3UwQy9XYW9EUnVPMkY1ekU2M3ZKYnhOOEFZczczMzgrNEI0SEJiNkJaNk9VZ2c5NlExNVJBNDEvZ0lxeGFWUHh5VHBEZlRVNUdmU0x4b2NkWWVuaXFxcEZNdFpHMm45ZDB1N0dzUU5jRmtOY0czcURabTR0RG84dFpidXltMGEyVmNGMkU1aEZFZ1hCYStYTEpDZlhpLzc3T3FBRWpQMHg3UWRrM0I0M3A4S0cvQmFpb1A1UnNWOHpCR3ZIMXpBZ3lQaGEyck43MC90VDEzeXJtUGQ1UVlFZnd6ZXhqS3JWNG1XSXVSZzhOVEhZU1pKVWFleUN3VG9tODBWRlVKWEcrR1lUVXl2NVcyMmFCY25vUkdpQ2lLRVlUTE9rZ1hlY2RLRlRIbWNJQWVqUTlXZWxyMGExOTZLcTg3dzVLTk1Da2NDR0Zud0JORkxtZm5icE5xVDZyVUJ4eHMzWDVudFg5ZDhIVnRTWUlOVHNHWFhNWkNKN2ZuYldhamhnL2FveDBGdEhYMjFlRjZxSUdUOGoxeitsMm9wVStnZ3dVZ2toVVVnQ0gyVGZxQmorTUxNVlZ2cGdxSnNQS3Q1ODJjYUZLQXJJRkl2Tys5UXVweExuRUgyaHowNFRNVGZuVTZiUUM2ejFidVZlN2grdE9MbmgxWVBGc0xRODhhbmliLzdUVEM4azlEc0JUcTBBU2U4UjJHYlNFc21POXFiYk13Z0VhWVVoT0t0R2V5UXNTSmRoU2s2WHhYVGhyV0w5RW53QkNYRGtJQ01xZG50QXh5eU05bldzWjRiTDlKSHFFeGdXVW1mV0NoelBGQXFuM0Y0eTg5NlVxSFRaeGxxM1dHeXBuNUhIY2VtMkhxZjNJVnhLSDFpbmhxZFZ0a3J5RWlUV3JJN1pkamJxbnFSYmwrV2d0UHRLT093ZURsQ2FSczNSMnFYY2JOZ1ZobGVNazRJV25GOEQxNjk1QWVuVTFMd0hqT0pMa0NqeGdORmlXQUZFUEg5YUVYQU1QTEV4QT09IiwNCiAgIkF1dGhvcml6YXRpb24iOiAiQVdTNC1ITUFDLVNIQTI1NiBDcmVkZW50aWFsPVhYWFhYWFhYWFhYWFhYWFhYWFgvMjAyMDA0MDEvdXMtZWFzdC0xL2FwcHN5bmMvYXdzNF9yZXF1ZXN0LCBTaWduZWRIZWFkZXJzPWFjY2VwdDtjb250ZW50LWVuY29kaW5nO2NvbnRlbnQtdHlwZTtob3N0O3gtYW16LWRhdGU7eC1hbXotc2VjdXJpdHktdG9rZW4sIFNpZ25hdHVyZT04M0VYQU1QTEViY2MxZmUzZWU2OWY3NWNkNWViYmY0Y2I0ZjE1MGU0Zjk5Y2VjODY5ZjE0OWM1RVhBTVBMRWRjIg0KfQ"]
```

**Header über Standard-HTTP-Header**

Bei dieser Methode werden der Host und die anderen Autorisierungsinformationen beim WebSocket Verbindungsaufbau mit dem Echtzeit-Endpunkt mithilfe von Standard-HTTP-Headern übertragen. AWS AppSync Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Die Anforderungsheader würden Folgendes beinhalten:

```
"sec-websocket-protocol" : ["graphql-ws"]
"accept": "application/json, text/javascript",
"content-encoding": "amz-1.0",
"content-type": "application/json; charset=UTF-8",
"host": "example1234567890000.appsync-api.us-east-1.amazonaws.com",
"x-amz-date": "20200401T001010Z",
"X-Amz-Security-Token": "AgEXAMPLEZ2luX2VjEAoaDmFwLXNvdXRoZWFEXAMPLEcwRQIgAh97Cljq7wOPL8KsxP3YtDuyc/9hAj8PhJ7Fvf38SgoCIQDhJEXAMPLEPspioOztj++pEagWCveZUjKEn0zyUhBEXAMPLEjj//////////8BEXAMPLExODk2NDgyNzg1NSIMo1mWnpESWUoYw4BkKqEFSrm3DXuL8w+ZbVc4JKjDP4vUCKNR6Le9C9pZp9PsW0NoFy3vLBUdAXEXAMPLEOVG8feXfiEEA+1khgFK/wEtwR+9zF7NaMMMse07wN2gG2tH0eKMEXAMPLEQX+sMbytQo8iepP9PZOzlZsSFb/dP5Q8hk6YEXAMPLEYcKZsTkDAq2uKFQ8mYUVA9EtQnNRiFLEY83aKvG/tqLWNnGlSNVx7SMcfovkFDqQamm+88y1OwwAEYK7qcoceX6Z7GGcaYuIfGpaX2MCCELeQvZ+8WxEgOnIfz7GYvsYNjLZSaRnV4G+ILY1F0QNW64S9Nvj+BwDg3ht2CrNvpwjVYlj9U3nmxE0UG5ne83LL5hhqMpm25kmL7enVgw2kQzmU2id4IKu0C/WaoDRuO2F5zE63vJbxN8AYs7338+4B4HBb6BZ6OUgg96Q15RA41/gIqxaVPxyTpDfTU5GfSLxocdYeniqqpFMtZG2n9d0u7GsQNcFkNcG3qDZm4tDo8tZbuym0a2VcF2E5hFEgXBa+XLJCfXi/77OqAEjP0x7Qdk3B43p8KG/BaioP5RsV8zBGvH1zAgyPha2rN70/tT13yrmPd5QYEfwzexjKrV4mWIuRg8NTHYSZJUaeyCwTom80VFUJXG+GYTUyv5W22aBcnoRGiCiKEYTLOkgXecdKFTHmcIAejQ9Welr0a196Kq87w5KNMCkcCGFnwBNFLmfnbpNqT6rUBxxs3X5ntX9d8HVtSYINTsGXXMZCJ7fnbWajhg/aox0FtHX21eF6qIGT8j1z+l2opU+ggwUgkhUUgCH2TfqBj+MLMVVvpgqJsPKt582caFKArIFIvO+9QupxLnEH2hz04TMTfnU6bQC6z1buVe7h+tOLnh1YPFsLQ88anib/7TTC8k9DsBTq0ASe8R2GbSEsmO9qbbMwgEaYUhOKtGeyQsSJdhSk6XxXThrWL9EnwBCXDkICMqdntAxyyM9nWsZ4bL9JHqExgWUmfWChzPFAqn3F4y896UqHTZxlq3WGypn5HHcem2Hqf3IVxKH1inhqdVtkryEiTWrI7ZdjbqnqRbl+WgtPtKOOweDlCaRs3R2qXcbNgVhleMk4IWnF8D1695AenU1LwHjOJLkCjxgNFiWAFEPH9aEXAMPLExA==",
"Authorization": "AWS4-HMAC-SHA256 Credential=XXXXXXXXXXXXXXXXXXX/20200401/us-east-1/appsync/aws4_request, SignedHeaders=accept;content-encoding;content-type;host;x-amz-date;x-amz-security-token, Signature=83EXAMPLEbcc1fe3ee69f75cd5ebbf4cb4f150e4f99cec869f149c5EXAMPLEdc"
```

Um die Anfrage mit einer benutzerdefinierten Domain zu signieren:

```
{
  url: "https://api.example.com/graphql/connect",
  data: "{}",
  method: "POST",
  headers: {
    "accept": "application/json, text/javascript",
    "content-encoding": "amz-1.0",
    "content-type": "application/json; charset=UTF-8",
  }
}
```

**Beispiel**

```
{
  "accept": "application/json, text/javascript",
  "content-encoding": "amz-1.0",
  "content-type": "application/json; charset=UTF-8",
  "host": "api.example.com",
  "x-amz-date": "20200401T001010Z",
  "X-Amz-Security-Token": "AgEXAMPLEZ2luX2VjEAoaDmFwLXNvdXRoZWFEXAMPLEcwRQIgAh97Cljq7wOPL8KsxP3YtDuyc/9hAj8PhJ7Fvf38SgoCIQDhJEXAMPLEPspioOztj++pEagWCveZUjKEn0zyUhBEXAMPLEjj//////////8BEXAMPLExODk2NDgyNzg1NSIMo1mWnpESWUoYw4BkKqEFSrm3DXuL8w+ZbVc4JKjDP4vUCKNR6Le9C9pZp9PsW0NoFy3vLBUdAXEXAMPLEOVG8feXfiEEA+1khgFK/wEtwR+9zF7NaMMMse07wN2gG2tH0eKMEXAMPLEQX+sMbytQo8iepP9PZOzlZsSFb/dP5Q8hk6YEXAMPLEYcKZsTkDAq2uKFQ8mYUVA9EtQnNRiFLEY83aKvG/tqLWNnGlSNVx7SMcfovkFDqQamm+88y1OwwAEYK7qcoceX6Z7GGcaYuIfGpaX2MCCELeQvZ+8WxEgOnIfz7GYvsYNjLZSaRnV4G+ILY1F0QNW64S9Nvj+BwDg3ht2CrNvpwjVYlj9U3nmxE0UG5ne83LL5hhqMpm25kmL7enVgw2kQzmU2id4IKu0C/WaoDRuO2F5zE63vJbxN8AYs7338+4B4HBb6BZ6OUgg96Q15RA41/gIqxaVPxyTpDfTU5GfSLxocdYeniqqpFMtZG2n9d0u7GsQNcFkNcG3qDZm4tDo8tZbuym0a2VcF2E5hFEgXBa+XLJCfXi/77OqAEjP0x7Qdk3B43p8KG/BaioP5RsV8zBGvH1zAgyPha2rN70/tT13yrmPd5QYEfwzexjKrV4mWIuRg8NTHYSZJUaeyCwTom80VFUJXG+GYTUyv5W22aBcnoRGiCiKEYTLOkgXecdKFTHmcIAejQ9Welr0a196Kq87w5KNMCkcCGFnwBNFLmfnbpNqT6rUBxxs3X5ntX9d8HVtSYINTsGXXMZCJ7fnbWajhg/aox0FtHX21eF6qIGT8j1z+l2opU+ggwUgkhUUgCH2TfqBj+MLMVVvpgqJsPKt582caFKArIFIvO+9QupxLnEH2hz04TMTfnU6bQC6z1buVe7h+tOLnh1YPFsLQ88anib/7TTC8k9DsBTq0ASe8R2GbSEsmO9qbbMwgEaYUhOKtGeyQsSJdhSk6XxXThrWL9EnwBCXDkICMqdntAxyyM9nWsZ4bL9JHqExgWUmfWChzPFAqn3F4y896UqHTZxlq3WGypn5HHcem2Hqf3IVxKH1inhqdVtkryEiTWrI7ZdjbqnqRbl+WgtPtKOOweDlCaRs3R2qXcbNgVhleMk4IWnF8D1695AenU1LwHjOJLkCjxgNFiWAFEPH9aEXAMPLExA==",
  "Authorization": "AWS4-HMAC-SHA256 Credential=XXXXXXXXXXXXXXXXXXX/20200401/us-east-1/appsync/aws4_request, SignedHeaders=accept;content-encoding;content-type;host;x-amz-date;x-amz-security-token, Signature=83EXAMPLEbcc1fe3ee69f75cd5ebbf4cb4f150e4f99cec869f149c5EXAMPLEdc"
}
```

**URL mit Abfragezeichenfolge anfordern**

```
wss://api.example.com/graphql?header=eyEXAMPLEHQiOiJhcHBsaWNhdGlvbi9qc29uLCB0ZXh0L2phdmFEXAMPLEQiLCJjb250ZW50LWVuY29kaW5nIjoEXAMPLEEuMCIsImNvbnRlbnQtdHlwZSI6ImFwcGxpY2F0aW9EXAMPLE47IGNoYXJzZXQ9VVRGLTgiLCJob3N0IjoiZXhhbXBsZEXAMPLENjc4OTAwMDAuYXBwc3luYy1hcGkudXMtZWFzdC0xLmFtYEXAMPLEcy5jb20iLCJ4LWFtei1kYXRlIjoiMjAyMDA0MDFUMDAxMDEwWiIsIlgtEXAMPLElY3VyaXR5LVRva2VuIjoiQWdvSmIzSnBaMmx1WDJWakVBb2FEbUZ3TFhOdmRYUm9aV0Z6ZEMweUlrY3dSUUlnQWg5N0NsanE3d09QTDhLc3hQM1l0RHV5Yy85aEFqOFBoSjdGdmYzOFNnb0NJUURoSllKYkpsbmpQc3Bpb096dGorK3BFYWdXQ3ZlWlVqS0VuMHp5VWhCbXhpck5CUWpqLy8vLy8vLy8vLzhCRUFBYUREY3hPRGsyTkRneU56ZzFOU0lNbzFtV25wRVNXVW9ZdzRCa0txRUZTcm0zRFh1TDh3K1piVmM0SktqRFA0dlVDS05SNkxlOUM5cFpwOVBzVzBOb0Z5M3ZMQlVkQVh3dDZQSld1T1ZHOGZlWGZpRUVBKzFraGdGSy93RXR3Uis5ekY3TmFNTU1zZTA3d04yZ0cydEgwZUtNVFhuOEF3QVFYK3NNYnl0UW84aWVwUDlQWk96bFpzU0ZiL2RQNVE4aGs2WWpHVGFMMWVZY0tac1RrREFxMnVLRlE4bVlVVkE5RXRRbk5SaUZMRVk4M2FLdkcvdHFMV05uR2xTTlZ4N1NNY2ZvdmtGRHFRYW1tKzg4eTFPd3dBRVlLN3Fjb2NlWDZaN0dHY2FZdUlmR3BhWDJNQ0NFTGVRdlorOFd4RWdPbklmejdHWXZzWU5qTFpTYVJuVjRHK0lMWTFGMFFOVzY0UzlOdmorQndEZzNodDJDck52cHdqVllsajlVM25teEUwVUc1bmU4M0xMNWhocU1wbTI1a21MN2VuVmd3MmtRem1VMmlkNElLdTBDL1dhb0RSdU8yRjV6RTYzdkpieE44QVlzNzMzOCs0QjRIQmI2Qlo2T1VnZzk2UTE1UkE0MS9nSXF4YVZQeHlUcERmVFU1R2ZTTHhvY2RZZW5pcXFwRk10WkcybjlkMHU3R3NRTmNGa05jRzNxRFptNHREbzh0WmJ1eW0wYTJWY0YyRTVoRkVnWEJhK1hMSkNmWGkvNzdPcUFFalAweDdRZGszQjQzcDhLRy9CYWlvUDVSc1Y4ekJHdkgxekFneVBoYTJyTjcwL3RUMTN5cm1QZDVRWUVmd3pleGpLclY0bVdJdVJnOE5USFlTWkpVYWV5Q3dUb204MFZGVUpYRytHWVRVeXY1VzIyYUJjbm9SR2lDaUtFWVRMT2tnWGVjZEtGVEhtY0lBZWpROVdlbHIwYTE5NktxODd3NUtOTUNrY0NHRm53Qk5GTG1mbmJwTnFUNnJVQnh4czNYNW50WDlkOEhWdFNZSU5Uc0dYWE1aQ0o3Zm5iV2FqaGcvYW94MEZ0SFgyMWVGNnFJR1Q4ajF6K2wyb3BVK2dnd1Vna2hVVWdDSDJUZnFCaitNTE1WVnZwZ3FKc1BLdDU4MmNhRktBcklGSXZPKzlRdXB4TG5FSDJoejA0VE1UZm5VNmJRQzZ6MWJ1VmU3aCt0T0xuaDFZUEZzTFE4OGFuaWIvN1RUQzhrOURzQlRxMEFTZThSMkdiU0VzbU85cWJiTXdnRWFZVWhPS3RHZXlRc1NKZGhTazZYeFhUaHJXTDlFbndCQ1hEa0lDTXFkbnRBeHl5TTluV3NaNGJMOUpIcUV4Z1dVbWZXQ2h6UEZBcW4zRjR5ODk2VXFIVFp4bHEzV0d5cG41SEhjZW0ySHFmM0lWeEtIMWluaHFkVnRrcnlFaVRXckk3WmRqYnFucVJibCtXZ3RQdEtPT3dlRGxDYVJzM1IycVhjYk5nVmhsZU1rNElXbkY4RDE2OTVBZW5VMUx3SGpPSkxrQ2p4Z05GaVdBRkVQSDlhTklhcXMvWnhBPT0iLCJBdXRob3JpemF0aW9uIjoiQVdTNC1ITUFDLVNIQTI1NiBDcmVkZW50aWFsPVhYWFhYWFhYWFhYWFhYWFhYWFgvMjAxOTEwMDIvdXMtZWFzdC0xEXAMPLE5bmMvYXdzNF9yZXF1ZXN0LCBTaWduZWRIZWFkZXJzPWFjY2VwdDtjb250ZWEXAMPLE29kaW5nO2NvbnRlbnQtdHlwZTtob3EXAMPLEW16LWRhdGU7eC1hbXotc2VjdXJpdHktdG9rZW4sIFNpZ25hdHVyZT04MzE4EXAMPLEiY2MxZmUzZWU2OWY3NWNkEXAMPLE0Y2I0ZjE1MGU0Zjk5Y2VjODY5ZjE0OWM1ZDAzNDEXAMPLEn0=&payload=e30=
```

**Anmerkung**  
Eine WebSocket Verbindung kann mehrere Abonnements haben (auch mit unterschiedlichen Authentifizierungsmodi). Eine Möglichkeit, dies zu implementieren, besteht darin, eine WebSocket Verbindung für das erste Abonnement herzustellen und sie dann zu schließen, wenn das letzte Abonnement nicht registriert ist. Sie können dies optimieren, indem Sie einige Sekunden warten, bevor Sie die WebSocket Verbindung schließen, falls die App unmittelbar nach der Aufhebung der Registrierung des letzten Abonnements abonniert wird. Beispiel: Wenn eine mobile App von einem Bildschirm auf einen anderen wechselt, beendet sie beim *Aushängen* ein Abonnement und beim Einhängen des Ereignisses *startet* sie ein anderes Abonnement.

### Lambda-Autorisierung
<a name="lambda-auth"></a>

#### Lambda-Autorisierungsheader
<a name="lambda-auth-list"></a>

**Inhalt der Kopfzeile**
+  `"Authorization": <string>`: Der Wert, der als übergeben wird`authorizationToken`.
+  `"host": <string>`: Der Host für den AWS AppSync GraphQL-Endpunkt oder Ihren benutzerdefinierten Domainnamen.

**Beispiel**

```
{
    "Authorization":"M0UzQzM1MkQtMkI0Ni00OTZCLUI1NkQtMUM0MTQ0QjVBRTczCkI1REEzRTIxLTk5NzItNDJENi1BQjMwLTFCNjRFNzQ2NzlCNQo=",
    "host":"example1234567890000.appsync-api.us-east-1.amazonaws.com"
}
```

**Header per Abfragezeichenfolge**

Zunächst wird ein JSON-Objekt, das das `host` und `Authorization` das enthält, in eine Zeichenfolge umgewandelt. Als Nächstes wird diese Zeichenfolge mithilfe der Base64-Kodierung codiert. Die resultierende Base64-kodierte Zeichenfolge wird als Abfrageparameter mit dem Namen der WebSocket URL hinzugefügt`header`, um die Verbindung mit dem Echtzeit-Endpunkt herzustellen. AWS AppSync Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql?header=eyJBdXRob3JpemF0aW9uIjoiZXlKcmFXUWlPaUpqYkc1eGIzQTVlVzVNSzA5UVlYSXJNVEpIV0VGTFNYQmllVTVXTkhoc1FqaFBWVzlZTW5NMldsZHZQU0lzSW1Gc1p5STZJbEpUTWpVMkluMC5leUp6ZFdJaU9pSmhObU5tTWpjd055MHhOamd4TFRRMU5ESXRPV1l4T0MxbE5qWTBNVGcyTmpsa016WWlMQ0psZG1WdWRGOXBaQ0k2SW1Wa016TTVNbU5rTFdOallUTXROR00yT0MxaE5EWXlMVEpsWkdJM1pUTm1ZMkZqWmlJc0luUnZhMlZ1WDNWelpTSTZJbUZqWTJWemN5SXNJbk5qYjNCbElqb2lZWGR6TG1OdloyNXBkRzh1YzJsbmJtbHVMblZ6WlhJdVlXUnRhVzRpTENKaGRYUm9YM1JwYldVaU9qRTFOamswTlRjM01UZ3NJbWx6Y3lJNkltaDBkSEJ6T2x3dlhDOWpiMmR1YVhSdkxXbGtjQzVoY0MxemIzVjBhR1ZoYzNRdE1pNWhiV0Y2YjI1aGQzTXVZMjl0WEM5aGNDMXpiM1YwYUdWaGMzUXRNbDgzT0hZMFNWWmliVkFpTENKbGVIQWlPakUxTmprME5qRXpNakFzSW1saGRDSTZNVFUyT1RRMU56Y3lNQ3dpYW5ScElqb2lOVGd6WmpobVltTXRNemsyTVMwMFl6QTRMV0poWlRBdFl6UXlZMkl4TVRNNU5EWTVJaXdpWTJ4cFpXNTBYMmxrSWpvaU0zRmxhalZsTVhabU16ZDFOM1JvWld3MGRHOTFkREprTVd3aUxDSjFjMlZ5Ym1GdFpTSTZJbVZzYjNKNllXWmxJbjAuQjRjZEp0aDNLRk5wSjZpa1ZwN2U2RFJlZTk1VjZRaS16RUUyREpIN3NIT2wyenhZaTdmLVNtRUdvaDJBRDhlbXhRUllhakJ5ei1yRTRKaDBRT3ltTjJZcy1aSWtNcFZCVFBndS1UTVdEeU9IaERVbVVqMk9QODJ5ZVozd2xaQXRyX2dNNEx6alhVWG1JX0syeUdqdVhmWFRhYTFtdlFFQkcwbVFmVmQ3U2Z3WEItamN2NFJZVmk2ajI1cWdvdzlFdzUydWZ1clBxYUstM1dBS0czMktwVjhKNC1XZWpxOHQwYy15QTdzYjhFbkI1NTFiN1RVOTN1S1JpVlZLM0U1NU5rNUFEUG9hbV9XWUU0NWkzczVxVkFQXy1Jblc3NU5Vb09DR1RzUzhZV01mYjZlY0hZSi0xai1iekEyN3phVDlWamN0WG45YnlORlptS0xwQTJMY3h3IiwiaG9zdCI6ImV4YW1wbGUxMjM0NTY3ODkwMDAwLmFwcHN5bmMtYXBpLnVzLWVhc3QtMS5hbWF6b25hd3MuY29tIn0=&payload=e30=
```

Es ist wichtig zu beachten, dass neben dem Base64-codierten Header-Objekt auch ein leeres JSON-Objekt \$1\$1 Base64-codiert und als separater Abfrageparameter in der URL enthalten ist. `payload` WebSocket

**Header über `Sec-WebSocket-Protocol`**

Ein JSON-Objekt, das das `host` und das enthält, `Authorization` wird in eine Zeichenfolge konvertiert und dann mit der Base64URL-Codierung codiert. Der resultierenden Base64URL-codierten Zeichenfolge wird ein Präfix vorangestellt. `header-` Diese Zeichenfolge mit Präfix wird dann zusätzlich zum `Sec-WebSocket-Protocol` Header als neues Unterprotokoll verwendet, wenn die Verbindung mit dem `graphql-ws` Echtzeit-Endpunkt hergestellt wird. WebSocket AWS AppSync 

Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Der `Sec-WebSocket-Protocol` Header enthält den folgenden Wert:

```
"sec-websocket-protocol" : ["graphql-ws", "header-ewogICAgImhvc3QiOiJleGFtcGxlMTIzNDU2Nzg5MDAwMC5hcHBzeW5jLWFwaS51cy1lYXN0LTEuYW1hem9uYXdzLmNvbSIsCiAgICAieC1hcGkta2V5IjoiZGEyLTEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Igp9"]
```

**Header über Standard-HTTP-Header**

Bei dieser Methode werden die Host- und Autorisierungsinformationen beim WebSocket Verbindungsaufbau mit dem Echtzeit-Endpunkt mithilfe von Standard-HTTP-Headern übertragen. AWS AppSync Die resultierende Anforderungs-URL hat die folgende Form:

```
wss://example1234567890000.appsync-realtime-api.us-east-1.amazonaws.com/graphql
```

Die Anforderungsheader würden Folgendes beinhalten:

```
"sec-websocket-protocol" : ["graphql-ws"]
"Authorization":"eyEXAMPLEiJjbG5xb3A5eW5MK09QYXIrMTJHWEFLSXBieU5WNHhsQjEXAMPLEnM2WldvPSIsImFsZyI6IlEXAMPLEn0.eyEXAMPLEiJhNmNmMjcwNy0xNjgxLTQ1NDItOWYxOC1lNjY0MTg2NjlkMzYiLCJldmVudF9pZCI6ImVkMzM5MmNkLWNjYTMtNGM2OC1hNDYyLTJlZGI3ZTNmY2FjZiIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoiYXdzLmNvZ25pdG8uc2lnbmluLnVzZXIuYWRtaW4iLCJhdXRoX3RpbWUiOjE1Njk0NTc3MTgsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC5hcC1zb3V0aGVhc3QtMi5hbWF6b25hd3MuY29tXC9hcC1zb3V0aGVhc3QtMl83OHY0SVZibVAiLCJleHAiOjE1Njk0NjEzMjAsImlhdCI6MTU2OTQ1NzcyMCwianRpIjoiNTgzZjhmYmMtMzk2MS00YzA4LWJhZTAtYzQyY2IxMTM5NDY5IiwiY2xpZW50X2lkIjoiM3FlajVlMXZmMzd1N3RoZWw0dG91dDJkMWwiLCJ1c2VybmFtZSI6ImVsb3EXAMPLEn0.B4EXAMPLEFNpJ6ikVp7e6DRee95V6Qi-zEE2DJH7sHOl2zxYi7f-SmEGoh2AD8emxQRYajByz-rE4Jh0QOymN2Ys-ZIkMpVBTPgu-TMWDyOHhDUmUj2OP82yeZ3wlZAtr_gM4LzjXUXmI_K2yGjuXfXTaa1mvQEBG0mQfVd7SfwXB-jcv4RYVi6j25qgow9Ew52ufurPqaK-3WAKG32KpV8J4-Wejq8t0c-yA7sb8EnB551b7TU93uKRiVVK3E55Nk5ADPoam_WYE45i3s5qVAP_-InW75NUoOCGTsS8YWMfb6ecHYJ-1j-bzA27zaT9VjctXn9byNFZmEXAMPLExw",
"host":"example1234567890000.appsync-api.us-east-1.amazonaws.com"
```

## Betrieb in Echtzeit WebSocket
<a name="real-time-websocket-operation"></a>

Nach dem Initiieren eines erfolgreichen WebSocket Handshakes mit muss der Client eine nachfolgende Nachricht senden AWS AppSync, mit der er sich AWS AppSync für verschiedene Operationen verbinden kann. Diese Nachrichten benötigen die folgenden Daten:
+  `type`: Typ der Operation.
+  `id`: Eine eindeutige Kennung für das Abonnement. Für diesen Zweck sollte eine UUID verwendet werden.
+  `payload`: Die zugehörige Nutzlast, abhängig vom Vorgangstyp.

Das `type` Feld ist das einzige Pflichtfeld; die `payload` Felder `id` und sind optional.

### Reihenfolge der Ereignisse
<a name="sequence-of-events"></a>

Um die Abonnementanfrage erfolgreich zu initiieren, einzurichten, zu registrieren und zu verarbeiten, muss der Kunde die folgende Reihenfolge einhalten:

1. Initialisierung der Verbindung (`connection_init`)

1. Bestätigung der Verbindung (`connection_ack`)

1. Registrierung des Abonnements (`start`)

1. Bestätigung des Abonnements (`start_ack`)

1. Verarbeitung des Abonnements (`data`)

1. Aufhebung der Registrierung des Abonnements (`stop`)

## Nachricht über die Initialisierung der Verbindung
<a name="connection-init-message"></a>

(Optional) Nach einem erfolgreichen Handshake kann der Client die `connection_init` Nachricht senden, um mit der Kommunikation mit dem AWS AppSync Echtzeit-Endpunkt zu beginnen. Die Nachricht ist eine Zeichenfolge, die durch die Stringifizierung des JSON-Objekts wie folgt abgerufen wurde:

```
{ "type": "connection_init" }
```

## Nachricht über die Bestätigung der Verbindung
<a name="connection-acknowledge-message"></a>

Nach dem Senden der Nachricht `connection_init` muss der Client auf die Nachricht `connection_ack` warten. Alle Nachrichten, die vor dem Empfang gesendet wurden, `connection_ack` werden ignoriert. Die Nachricht sollte wie folgt lauten:

```
{
  "type": "connection_ack",
  "payload": {
    // Time in milliseconds waiting for ka message before the client should terminate the WebSocket connection
    "connectionTimeoutMs": 300000
  }
}
```

## Keep-Alive-Nachricht
<a name="keep-alive-message"></a>

Zusätzlich zur Verbindungsbestätigungsnachricht empfängt der Client regelmäßig Keep-Alive-Nachrichten. Wenn der Client innerhalb des Verbindungstimeouts keine Keep-Alive-Nachricht erhält, sollte der Client die Verbindung schließen. AWS AppSync sendet weiterhin diese Nachrichten und verwaltet die registrierten Abonnements, bis die Verbindung automatisch beendet wird (nach 24 Stunden). Keep-Alive-Nachrichten sind Heartbeats und müssen vom Client nicht bestätigt werden.

```
{ "type": "ka" }
```

## Nachricht über die Abonnementregistrierung
<a name="subscription-registration-message"></a>

Nachdem der Client eine `connection_ack` Nachricht erhalten hat, kann er Abonnementregistrierungsnachrichten an senden. AWS AppSync Bei diesem Nachrichtentyp handelt es sich um ein stringifiziertes JSON-Objekt, das die folgenden Felder enthält:
+  `"id": <string>`: Die ID des Abonnements. Diese ID muss für jedes Abonnement eindeutig sein, andernfalls gibt der Server einen Fehler zurück, der darauf hinweist, dass die Abonnement-ID doppelt vorhanden ist.
+  `"type": "start"`: Ein konstanter `<string>`-Parameter.
+  `"payload": <Object>`: Ein Objekt, das die für das Abonnement relevanten Informationen enthält.
  +  `"data": <string>`: Ein stringifiziertes JSON-Objekt, das eine GraphQL-Abfrage und Variablen enthält.
    +  `"query": <string>`: Eine GraphQL-Operation.
    +  `"variables": <Object>`: Ein Objekt, das die Variablen für die Abfrage enthält.
  +  `"extensions": <Object>`: Ein Objekt, das ein Autorisierungsobjekt enthält.
+  `"authorization": <Object>`: Ein Objekt, das die für die Autorisierung erforderlichen Felder enthält.

### Autorisierungsobjekt für die Abonnementregistrierung
<a name="authorization-object-for-subscription-registration"></a>

Für das Autorisierungsobjekt gelten dieselben Regeln wie im [Das Format der Header-Parameter basiert auf dem AWS AppSync API-Autorisierungsmodus](#header-parameter-format-based-on-appsync-api-authorization-mode) Abschnitt. Die einzige Ausnahme ist IAM, wo sich die SigV4-Signaturinformationen geringfügig unterscheiden. Weitere Details finden Sie im IAM-Beispiel.

Beispiel mit Verwendung von Amazon Cognito-Benutzerpools:

```
{
  "id": "ee849ef0-cf23-4cb8-9fcb-152ae4fd1e69",
  "payload": {
    "data": "{\"query\":\"subscription onCreateMessage {\\n onCreateMessage {\\n __typename\\n message\\n }\\n }\",\"variables\":{}}",
      "extensions": {
        "authorization": {
          "Authorization": "eyEXAMPLEiJjbG5xb3A5eW5MK09QYXIrMTJEXAMPLEBieU5WNHhsQjhPVW9YMnM2WldvPSIsImFsZyI6IlEXAMPLEn0.eyJzdWIiOiJhNmNmMjcwNy0xNjgxLTQ1NDItEXAMPLENjY0MTg2NjlkMzYiLCJldmVudF9pZCI6ImU3YWVmMzEyLWUEXAMPLEY0Zi04YjlhLTRjMWY5M2Q5ZTQ2OCIsInRva2VuX3VzZSI6ImFjY2VzcyIsIEXAMPLEIjoiYXdzLmNvZ25pdG8uc2lnbmluLnVzZXIuYWRtaW4iLCJhdXRoX3RpbWUiOjE1Njk2MTgzMzgsImlzcyI6Imh0dEXAMPLEXC9jb2duaXRvLWlkcC5hcC1zb3V0aGVhc3QtMi5hbWF6b25hd3MuY29tXC9hcC1zbEXAMPLEc3QtMl83OHY0SVZibVAiLCJleHAiOjE1NzAyNTQ3NTUsImlhdCI6MTU3MDI1MTE1NSwianRpIjoiMmIEXAMPLEktZTVkMi00ZDhkLWJiYjItNjA0YWI4MDEwOTg3IiwiY2xpZW50X2lkIjoiM3FlajVlMXZmMzd1EXAMPLE0dG91dDJkMWwiLCJ1c2VybmFtZSI6ImVsb3J6YWZlIn0.CT-qTCtrYeboUJ4luRSTPXaNewNeEXAMPLE14C6sfg05tO0fOMpiUwj9k19gtNCCMqoSsjtQoUweFnH4JYa5EXAMPLEVxOyQEQ4G7jQrt5Ks6STn53vuseR3zRW9snWgwz7t3ZmQU-RWvW7yQU3sNQRLEXAMPLEcd0yufBiCYs3dfQxTTdvR1B6Wz6CD78lfNeKqfzzUn2beMoup2h6EXAMPLE4ow8cUPUPvG0DzRtHNMbWskjPanu7OuoZ8iFO_Eot9kTtAlVKYoNbWkZhkD8dxutyoU4RSH5JoLAnrGF5c8iKgv0B2dfEXAMPLEIihxaZVJ9w9w48S4EXAMPLEcA",
          "host": "example1234567890000.appsync-api.us-east-1.amazonaws.com"
         }
      }
  },
  "type": "start"
}
```

Beispiel mit Verwendung von IAM:

```
{
  "id": "eEXAMPLE-cf23-1234-5678-152EXAMPLE69",
  "payload": {
    "data": "{\"query\":\"subscription onCreateMessage {\\n onCreateMessage {\\n __typename\\n message\\n }\\n }\",\"variables\":{}}",
    "extensions": {
      "authorization": {
        "accept": "application/json, text/javascript",
        "content-type": "application/json; charset=UTF-8",
        "X-Amz-Security-Token": "AgEXAMPLEZ2luX2VjEAoaDmFwLXNvdXRoZWFEXAMPLEcwRQIgAh97Cljq7wOPL8KsxP3YtDuyc/9hAj8PhJ7Fvf38SgoCIQDhJEXAMPLEPspioOztj++pEagWCveZUjKEn0zyUhBEXAMPLEjj//////////8BEXAMPLExODk2NDgyNzg1NSIMo1mWnpESWUoYw4BkKqEFSrm3DXuL8w+ZbVc4JKjDP4vUCKNR6Le9C9pZp9PsW0NoFy3vLBUdAXEXAMPLEOVG8feXfiEEA+1khgFK/wEtwR+9zF7NaMMMse07wN2gG2tH0eKMEXAMPLEQX+sMbytQo8iepP9PZOzlZsSFb/dP5Q8hk6YEXAMPLEYcKZsTkDAq2uKFQ8mYUVA9EtQnNRiFLEY83aKvG/tqLWNnGlSNVx7SMcfovkFDqQamm+88y1OwwAEYK7qcoceX6Z7GGcaYuIfGpaX2MCCELeQvZ+8WxEgOnIfz7GYvsYNjLZSaRnV4G+ILY1F0QNW64S9Nvj+BwDg3ht2CrNvpwjVYlj9U3nmxE0UG5ne83LL5hhqMpm25kmL7enVgw2kQzmU2id4IKu0C/WaoDRuO2F5zE63vJbxN8AYs7338+4B4HBb6BZ6OUgg96Q15RA41/gIqxaVPxyTpDfTU5GfSLxocdYeniqqpFMtZG2n9d0u7GsQNcFkNcG3qDZm4tDo8tZbuym0a2VcF2E5hFEgXBa+XLJCfXi/77OqAEjP0x7Qdk3B43p8KG/BaioP5RsV8zBGvH1zAgyPha2rN70/tT13yrmPd5QYEfwzexjKrV4mWIuRg8NTHYSZJUaeyCwTom80VFUJXG+GYTUyv5W22aBcnoRGiCiKEYTLOkgXecdKFTHmcIAejQ9Welr0a196Kq87w5KNMCkcCGFnwBNFLmfnbpNqT6rUBxxs3X5ntX9d8HVtSYINTsGXXMZCJ7fnbWajhg/aox0FtHX21eF6qIGT8j1z+l2opU+ggwUgkhUUgCH2TfqBj+MLMVVvpgqJsPKt582caFKArIFIvO+9QupxLnEH2hz04TMTfnU6bQC6z1buVe7h+tOLnh1YPFsLQ88anib/7TTC8k9DsBTq0ASe8R2GbSEsmO9qbbMwgEaYUhOKtGeyQsSJdhSk6XxXThrWL9EnwBCXDkICMqdntAxyyM9nWsZ4bL9JHqExgWUmfWChzPFAqn3F4y896UqHTZxlq3WGypn5HHcem2Hqf3IVxKH1inhqdVtkryEiTWrI7ZdjbqnqRbl+WgtPtKOOweDlCaRs3R2qXcbNgVhleMk4IWnF8D1695AenU1LwHjOJLkCjxgNFiWAFEPH9aEXAMPLExA==",
        "Authorization": "AWS4-HMAC-SHA256 Credential=XXXXXXXXXXXXXXXXXXXX/20200401/us-east-1/appsync/aws4_request, SignedHeaders=accept;content-encoding;content-type;host;x-amz-date;x-amz-security-token, Signature=b90131a61a7c4318e1c35ead5dbfdeb46339a7585bbdbeceeaff51f4022eb1fd",
        "content-encoding": "amz-1.0",
        "host": "example1234567890000.appsync-api.us-east-1.amazonaws.com",
        "x-amz-date": "20200401T001010Z"
      }
    }
  },
  "type": "start"
}
```

Beispiel mit einem benutzerdefinierten Domainnamen:

```
{
  "id": "key-cf23-4cb8-9fcb-152ae4fd1e69",
  "payload": {
    "data": "{\"query\":\"subscription onCreateMessage {\\n onCreateMessage {\\n __typename\\n message\\n }\\n }\",\"variables\":{}}",
      "extensions": {
        "authorization": {
          "x-api-key": "da2-12345678901234567890123456",
          "host": "api.example.com"
         }
      }
  },
  "type": "start"
}
```

Die SigV4-Signatur muss nicht `/connect` an die URL angehängt werden, und die stringifizierte JSON-GraphQL-Operation ersetzt sie. `data` Im Folgenden finden Sie ein Beispiel für eine SigV4-Signaturanforderung:

```
{
  url: "https://example1234567890000.appsync-api.us-east-1.amazonaws.com/graphql",
  data: "{\"query\":\"subscription onCreateMessage {\\n onCreateMessage {\\n __typename\\n message\\n }\\n }\",\"variables\":{}}",
  method: "POST",
  headers: {
    "accept": "application/json, text/javascript",
    "content-encoding": "amz-1.0",
    "content-type": "application/json; charset=UTF-8",
  }
}
```

## Bestätigungsnachricht für das Abonnement
<a name="subscription-acknowledge-message"></a>

Nach dem Senden der Abonnementstartnachricht sollte der Client warten, AWS AppSync bis die Nachricht gesendet wird`start_ack`. Die `start_ack` Nachricht weist darauf hin, dass das Abonnement erfolgreich ist.

Beispiel für eine Abonnementbestätigung:

```
{
  "type": "start_ack",
  "id": "eEXAMPLE-cf23-1234-5678-152EXAMPLE69"
}
```

## Fehlermeldung
<a name="error-message"></a>

Wenn der Verbindungsaufbau oder die Abonnementregistrierung fehlschlägt oder wenn ein Abonnement vom Server aus beendet wird, sendet der Server eine Fehlermeldung an den Client. Tritt der Fehler während der Verbindungsinitialisierung auf, wird die Verbindung vom Server geschlossen.
+  `"type": "error"`: Ein konstanter `<string>`-Parameter.
+  `"id": <string>`: Die ID des entsprechenden registrierten Abonnements, falls relevant.
+  `"payload" <Object>`: Ein Objekt, das die entsprechenden Fehlerinformationen enthält.

Beispiel:

```
{
  "type": "error",
  "payload": {
    "errors": [
      {
        "errorType": "LimitExceededError",
        "message": "Rate limit exceeded"
      }
    ]
  }
}
```

## Verarbeitung von Datennachrichten
<a name="processing-data-messages"></a>

Wenn ein Client eine Mutation einreicht, AWS AppSync identifiziert er alle Abonnenten, die daran interessiert sind, und sendet eine `"type":"data"` Nachricht an jeden, der das entsprechende Abonnement `id` aus dem `"start"` Abonnementvorgang verwendet. Es wird erwartet, `id` dass der Client den Überblick über das von ihm gesendete Abonnement behält, sodass der Client, wenn er eine Datennachricht empfängt, diese dem entsprechenden Abonnement zuordnen kann.
+  `"type": "data"`: Ein konstanter `<string>`-Parameter.
+  `"id": <string>`: Die ID des entsprechenden registrierten Abonnements.
+  `"payload" <Object>`: Ein Objekt, das die Abonnementinformationen enthält.

Beispiel:

```
{
  "type": "data",
  "id": "ee849ef0-cf23-4cb8-9fcb-152ae4fd1e69",
  "payload": {
    "data": {
      "onCreateMessage": {
        "__typename": "Message",
        "message": "test"
      }
    }
  }
}
```

## Nachricht über die Aufhebung der Abonnementregistrierung
<a name="subscription-unregistration-message"></a>

Wenn die App die Abonnementereignisse nicht mehr abhören möchte, sollte der Client eine Nachricht mit dem folgenden stringifizierten JSON-Objekt senden:
+  `"type": "stop"`: Ein konstanter `<string>`-Parameter.
+  `"id": <string>`: Die ID des Abonnements, für das die Registrierung aufgehoben werden soll.

Beispiel:

```
{
  "type":"stop",
  "id":"ee849ef0-cf23-4cb8-9fcb-152ae4fd1e69"
}
```

AWS AppSync sendet eine Bestätigungsnachricht mit dem folgenden stringifizierten JSON-Objekt zurück:
+  `"type": "complete"`: Ein konstanter `<string>`-Parameter.
+  `"id": <string>`: Die ID des nicht registrierten Abonnements.

Nachdem der Client die Bestätigungsnachricht erhalten hat, erhält er keine weiteren Nachrichten für dieses spezielle Abonnement.

Beispiel:

```
{
  "type":"complete",
  "id":"eEXAMPLE-cf23-1234-5678-152EXAMPLE69"
}
```

## Trennen der Verbindung WebSocket
<a name="disconnecting-the-websocket"></a>

Um Datenverlust zu vermeiden, sollte der Client vor dem Trennen der Verbindung über die erforderliche Logik verfügen, um zu überprüfen, ob derzeit kein Vorgang über die WebSocket Verbindung ausgeführt wird. Vor dem Trennen der Verbindung mit dem sollten alle Abonnements abgemeldet werden. WebSocket

# Zusammenführen APIs AWS AppSync
<a name="merged-api"></a>

Wenn der Einsatz von GraphQL innerhalb eines Unternehmens zunimmt, können Kompromisse zwischen API ease-of-use - und API-Entwicklungsgeschwindigkeit entstehen. Einerseits setzen AWS AppSync Unternehmen GraphQL ein, um die Anwendungsentwicklung zu vereinfachen. Dies bietet 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 haben, API-Updates unabhängig voneinander zu erstellen, zu verwalten und bereitzustellen. Dies erhöht ihre Entwicklungsgeschwindigkeit. 

Um dieses Problem zu lösen, ermöglicht die AWS AppSync APIs Merged-Funktion 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 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 bietet den verschiedenen Teams, die an dieser API beteiligt sind, die Möglichkeit, API-Updates schnell und unabhängig voneinander vorzunehmen.

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

![\[Das Diagramm zeigt den zusammengeführten API-Workflow, bei dem mehrere Quellen APIs zu einem einzigen zusammengeführten API-Endpunkt kombiniert wurden\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/merged-api-workflow.png)


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 Quellenliste erstellen und anschließend alle mit der Quelle verknüpften Metadaten AWS AppSync APIs, APIs einschließlich Schema, Typen, Datenquellen, Resolver und Funktionen, zu einer neuen AWS AppSync zusammengeführten API zusammenführen.

Bei Zusammenführungen besteht die Möglichkeit, dass aufgrund von Inkonsistenzen im Inhalt der Quell-API-Daten, wie z. B. Typbenennungskonflikte beim Kombinieren mehrerer Schemas, ein Zusammenführungskonflikt auftritt. Für einfache Anwendungsfälle, in denen keine Definitionen in der Quelle in APIs Konflikt stehen, müssen die Quell-API-Schemas nicht geändert werden. Die daraus resultierende Merged API importiert einfach alle Typen, Resolver, Datenquellen und Funktionen aus der Originalquelle. AWS AppSync APIs In komplexen Anwendungsfällen, in denen Konflikte auftreten, users/teams müssen sie die Konflikte auf verschiedene Weise lösen. AWS AppSync stellt Benutzern mehrere Tools und Beispiele zur Verfügung, mit denen Zusammenführungskonflikte reduziert werden können. 

Nachfolgende Zusammenführungen, die in AWS AppSync konfiguriert sind, übertragen die in der Quelle vorgenommenen Änderungen APIs an die zugehörige zusammengeführte API.

## Zusammengeführt APIs und Verbund
<a name="merged-api-federation"></a>

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 in einer separaten, zusammengeführten API zusammengefasst APIs werden. 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 die Anforderungselemente auf die zugrunde liegenden Untergraphen/Server. In der folgenden Tabelle wird der Build-Time-Ansatz der AWS AppSync zusammengeführten API mit routerbasierten Laufzeitansätzen für die GraphQL-Schemakomposition verglichen:


|  |  |  | 
| --- |--- |--- |
| Feature | AppSync Zusammengeführte API | Router-basierte Lösungen | 
| Unterdiagramme werden unabhängig voneinander verwaltet | Ja | Ja | 
| Untergraphen können unabhängig voneinander adressiert werden | Ja | Ja | 
| Automatisierte Schemazusammenstellung | Ja | Ja | 
| Automatisierte Konflikterkennung | Ja | Ja | 
| Konfliktlösung über Schemadirektiven | Ja | Ja | 
| Unterstützte Subgraph-Server | AWS AppSync\$1 | Variiert | 
| Komplexität des Netzwerks | Eine einzige, zusammengeführte API bedeutet keine zusätzlichen Netzwerk-Hops. | Eine mehrschichtige Architektur erfordert die Planung und Delegierung von Abfragen, das Parsen und Serialisieren/Deserialisieren von Unterabfragen sowie Referenz-Resolver in Untergraphen, um Verknüpfungen durchzuführen. | 
| Unterstützung der Beobachtbarkeit | Integrierte Überwachung, Protokollierung und Rückverfolgung. Ein einziger, zusammengeführter API-Server bedeutet vereinfachtes Debugging. | Build-your-own Beobachtbarkeit über den Router und alle zugehörigen Subgraph-Server hinweg. Komplexes Debugging auf verteilten Systemen. | 
| Unterstützung bei der Autorisierung | Integrierte Unterstützung für mehrere Autorisierungsmodi. | Build-your-own Autorisierungsregeln. | 
| Kontenübergreifende Sicherheit | Integrierte Unterstützung für AWS cloudübergreifende Kontozuordnungen. | Build-your-own Sicherheitsmodell. | 
| Unterstützung für Abonnements | Ja | Nein | 

\$1 AWS AppSync Zusammengeführt APIs kann nur mit der AWS AppSync Quelle verknüpft werden APIs. 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 Merged APIs zu einer and/or 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](https://aws.amazon.com/blogs/mobile/federation-appsync-subgraph/) Federation with. AWS AppSync

**Topics**
+ [Zusammengeführt APIs und Verbund](#merged-api-federation)
+ [Konfliktlösung zusammengeführter APIs](#merged-api-conflict-resolution)
+ [Schemas konfigurieren](#configuring-schemas-merged-api)
+ [Autorisierungsmodi konfigurieren](#configuring-authorization-merged-api)
+ [Konfiguration von Ausführungsrollen](#execution-roles-merged-api)
+ [Konfiguration von Cross-Account-Zusammengeführt mit APIs AWS RAM](#cross-account-merged-api)
+ [Zusammenführen](#merges)
+ [Zusätzliche Unterstützung für Merged APIs](#merge-api-additional-support)
+ [Einschränkungen bei der zusammengeführten API](#merged-api-limits)
+ [Überlegungen zur zusammengeführten API](#merged-api-considerations)
+ [Zusammengeführt erstellen APIs](#creating-merged-api)

## Konfliktlösung zusammengeführter APIs
<a name="merged-api-conflict-resolution"></a>

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

### Richtlinien für zusammengeführte API-Schemas
<a name="merged-api-schema-directive"></a>

 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:
+ *@canonical*: Diese Direktive legt den Vorrang von Typen/Feldern mit ähnlichen Namen und Daten fest. Wenn zwei oder mehr Quellen denselben GraphQL-Typ oder dasselbe GraphQL-Feld APIs haben, APIs kann eine von ihnen ihren Typ oder ihr Feld als *kanonisch* annotieren, was bei der Zusammenführung priorisiert wird. Konflikte types/fields , die in anderen Quellen nicht mit dieser Direktive annotiert sind, werden beim Zusammenführen ignoriert. APIs 
+ *@hidden*: Diese Direktive kapselt bestimmte, um sie aus types/fields dem Zusammenführungsprozess zu entfernen. Teams möchten möglicherweise bestimmte Typen oder Operationen in der Quell-API entfernen oder verbergen, sodass nur interne Kunden auf bestimmte typisierte Daten zugreifen können. Wenn diese Direktive angehängt ist, werden Typen oder Felder nicht in der zusammengeführten API zusammengeführt. 
+ *@renamed*: Diese Direktive ändert die Namen von types/fields , um Namenskonflikte zu reduzieren. Es gibt Situationen, in denen verschiedene denselben Typ oder denselben Feldnamen APIs haben. Sie müssen jedoch alle im zusammengeführten Schema verfügbar sein. Eine einfache Möglichkeit, sie alle in die zusammengeführte API aufzunehmen, besteht darin, das Feld in etwas Ähnliches, aber anderes umzubenennen. 

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öchten APIs. 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 erstellen`Posts`. `putPost` Jede `Post` enthält einen Titel und eine ID. Die ID wird verwendet`User`, 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:
+ *Der `User` Typ aus *Source1.graphql hatte aufgrund* der @canonical -Annotation Vorrang vor dem `User` von *Source2.graphql*.*
+ *Der `Message` Typ aus Source1.graphql wurde in die Zusammenführung aufgenommen.* Bei dem `Message` von *Source2.graphql* gab es jedoch einen Namenskonflikt. Aufgrund seiner *@renamed* -Annotation wurde es ebenfalls in die Zusammenführung aufgenommen, jedoch mit dem alternativen Namen. `ChatMessage`
+ Der `Post` Typ aus *Source1.graphql* war enthalten, der `Post` Typ aus *Source2.graphql* jedoch nicht. Normalerweise würde es bei diesem Typ einen Konflikt geben, aber da der `Post` Typ aus *Source2.graphql* eine *@hidden* -Annotation hatte, wurden seine Daten verschleiert und nicht in die Zusammenführung aufgenommen. Dies führte zu keinen Konflikten.
+ Der `Query` Typ wurde aktualisiert, sodass er den Inhalt beider Dateien enthält. Eine `GetMessage` Abfrage wurde jedoch `GetChatMessage` aufgrund der Direktive in umbenannt. Dadurch wurde der Namenskonflikt zwischen den beiden Abfragen mit demselben Namen behoben.

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). `Reviews`sind 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:
+ Der `Mutation` Typ hatte keine Konflikte und wurde zusammengeführt.
+ Die `Post` Typfelder wurden im Rahmen einer Union-Operation kombiniert. Beachten Sie, wie durch die Vereinigung der beiden Elemente ein Single `id``title`, ein und ein Single entstanden sind`reviews`.
+ Für den `Review` Typ gab es keine Konflikte und er wurde zusammengeführt.
+ Der `Query` Typ hatte keine Konflikte und wurde zusammengeführt.

### Verwaltung von Resolvern auf gemeinsam genutzten Typen
<a name="resolvers-shared-types-merged-api"></a>

Stellen Sie sich im obigen Beispiel den Fall vor, dass *Source1.graphql* einen Unit-Resolver konfiguriert hat`Query.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 hat`Post.reviews`, auf dem zwei Funktionen ausgeführt werden. `Function1`hat eine `None` Datenquelle angehängt, um benutzerdefinierte Autorisierungsprüfungen durchzuführen. `Function2`hat 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 zunächst den Unit-Resolver für `Query.getPost` from aus`Source1`, 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 Resolverkonflikten bei gemeinsam genutzten Typen
<a name="resolver-conflict-shared-type-merged-api"></a>

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ält`PostInfo`, die von Source2.graphql aufgelöst werden.* *Source1.graphql* implementiert den an angehängten Resolver`Query.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 Quell-API-Schemas 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 alle Quellteams weiterhin klar sind.

## Schemas konfigurieren
<a name="configuring-schemas-merged-api"></a>

Zwei Parteien sind für die Konfiguration der Schemas verantwortlich, um eine zusammengeführte API zu erstellen:
+ **Besitzer zusammengeführter** APIs — Besitzer zusammengeführter APIs müssen die Autorisierungslogik der zusammengeführten API und erweiterte Einstellungen wie Protokollierung, Tracing, Caching und WAF-Unterstützung konfigurieren.
+ Eigentümer der **assoziierten Quell-API — Besitzer** assoziierter APIs müssen die Schemas, Resolver und Datenquellen konfigurieren, aus denen die zusammengeführte API besteht.

**Da das Schema Ihrer zusammengeführten API aus den Schemas Ihrer verknüpften Quelle erstellt wird APIs, 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 mithilfe der Dropdownliste über dem Schemafenster zwischen Ihrem zusammengeführten Schema und den einzelnen Schemas der Quelle, die in Ihrer zusammengeführten API APIs enthalten ist, wechseln.**

## Autorisierungsmodi konfigurieren
<a name="configuring-authorization-merged-api"></a>

Zum Schutz Ihrer zusammengeführten API stehen mehrere Autorisierungsmodi zur Verfügung. Weitere Informationen zu den Autorisierungsmodi finden Sie unter [Autorisierung und Authentifizierung](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html). AWS AppSync

Die folgenden Autorisierungsmodi stehen für Merged zur Verfügung APIs:
+  **API-Schlüssel**: Die einfachste Autorisierungsstrategie. Alle Anfragen müssen einen API-Schlüssel unter dem `x-api-key` Anforderungsheader enthalten. Abgelaufene API-Schlüssel werden 60 Tage nach dem Ablaufdatum aufbewahrt. 
+  **AWS Identity and Access Management (IAM): Die AWS IAM-Autorisierungsstrategie** **autorisiert alle Anfragen, die mit Sigv4 signiert sind.** 
+  **Amazon Cognito Cognito-Benutzerpools**: Autorisieren Sie Ihre Benutzer über Amazon Cognito Cognito-Benutzerpools, um eine genauere Kontrolle zu erhalten. 
+  **AWS Lambda Authorizers**: Eine serverlose Funktion, mit der Sie den Zugriff auf Ihre API mithilfe benutzerdefinierter Logik authentifizieren und autorisieren können. AWS AppSync 
+ **OpenID Connect**: Dieser Autorisierungstyp erzwingt OpenID Connect-Token (OIDC), die von einem OIDC-kompatiblen Dienst bereitgestellt werden. Ihre Anwendung kann Benutzer und Berechtigungen nutzen, die von Ihrem OIDC-Anbieter zur Kontrolle des Zugriffs definiert wurden.

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 auf einer Quell-API konfigurierten primären Autorisierungsmodus entweder als eigenen primären Autorisierungsmodus oder als sekundären Autorisierungsmodus enthalten. Andernfalls ist sie inkompatibel und der Zusammenführungsvorgang schlägt mit einem Konflikt fehl. Wenn Multi-Auth-Direktiven in der Quelle verwendet werden APIs, kann der Zusammenführungsprozess diese Direktiven automatisch mit dem vereinheitlichten 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.

## Konfiguration von Ausführungsrollen
<a name="execution-roles-merged-api"></a>

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 zusammengeführte API Resolver ausführt, die auf Daten aus den in Ihrer Quelle konfigurierten Datenquellen zugreifen. APIs Die dafür erforderliche Servicerolle ist die`mergedApiExecutionRole`, und sie muss über die `appsync:SourceGraphQL` IAM-Berechtigung expliziten Zugriff haben, um Anfragen auf der Quelle auszuführen, die in Ihrer zusammengeführten API 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 für IAM funktioniert. APIs Für non-top-level Felder AWS AppSync müssen Sie die Berechtigung für den Quell-API-ARN selbst definieren. Um den Zugriff auf bestimmte non-top-level Felder in der Merged-API einzuschränken, 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 behandelt, die für die 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 beschränken möchten, können Sie eine Richtlinie wie die folgende 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 AWS AppSync Konsolen-API-Erstellungsassistenten verwenden, um eine Servicerolle zu generieren, damit Ihre zusammengeführte API auf Ressourcen zugreifen kann APIs , die in der Quelle konfiguriert sind und sich in demselben Konto wie Ihre zusammengeführte API befinden. Falls sich Ihre Quelle APIs nicht in demselben Konto wie Ihre zusammengeführte API befindet, müssen Sie zunächst Ihre Ressourcen mithilfe von AWS Resource Access Manager (AWS RAM) gemeinsam nutzen. 

## Konfiguration von Cross-Account-Zusammengeführt mit APIs AWS RAM
<a name="cross-account-merged-api"></a>

Wenn Sie eine zusammengeführte API erstellen, 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) und 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 über eine einzige zusammengeführte API zu unterstützen. 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 einer AWS AppSync API im RAM zugeordnet werden können:

1. `AWSRAMPermissionAppSyncSourceApiOperationAccess`: Der Standard-Berechtigungssatz, der hinzugefügt wird, wenn eine AWS AppSync API gemeinsam genutzt wird, AWS RAM sofern keine andere Berechtigung angegeben ist. Dieser Berechtigungssatz wird für die gemeinsame Nutzung einer AWS AppSync Quell-API mit einem Besitzer einer zusammengeführten API verwendet. Dieser Berechtigungssatz umfasst die Berechtigung für `appsync:AssociateMergedGraphqlApi` die Quell-API sowie die für den Zugriff auf die Quell-API-Ressourcen zur Laufzeit erforderlichen `appsync:SourceGraphQL` Berechtigungen.

1. `AWSRAMPermissionAppSyncMergedApiOperationAccess`: Dieser Berechtigungssatz sollte konfiguriert werden, wenn eine zusammengeführte API mit einem Eigentümer der Quell-API geteilt wird. Dieser Berechtigungssatz gibt der Quell-API die Möglichkeit, die zusammengeführte API zu konfigurieren, einschließlich der Möglichkeit, jede Quelle, die dem Zielprinzipal APIs gehört, der zusammengeführten API zuzuordnen und die Quell-API-Verknüpfungen der zusammengeführten API zu lesen und zu aktualisieren.

1. `AWSRAMPermissionAppSyncAllowSourceGraphQLAccess`: Dieser Berechtigungssatz ermöglicht die Verwendung der `appsync:SourceGraphQL` Berechtigung mit einer AWS AppSync API. Es ist für die gemeinsame Nutzung einer Quell-API mit einem Eigentümer einer zusammengeführten API vorgesehen. Im Gegensatz zum Standardberechtigungssatz für den Zugriff auf Quell-API-Operationen umfasst dieser Berechtigungssatz nur die Laufzeitberechtigung`appsync:SourceGraphQL`. Wenn sich ein Benutzer dafür entscheidet, den Zugriff auf den Vorgang der zusammengeführten API mit einem Eigentümer der Quell-API zu teilen, muss er diese Berechtigung auch von der Quell-API an den Eigentümer der zusammengeführten API weitergeben, um über den Endpunkt der zusammengeführten API Laufzeitzugriff zu erhalten.

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:

1. `appsync:AssociateSourceGraphqlApi`

1. `appsync:AssociateMergedGraphqlApi`

1. `appsync:GetSourceApiAssociation`

1. `appsync:UpdateSourceApiAssociation`

1. `appsync:StartSchemaMerge`

1. `appsync:ListTypesByAssociation`

1. `appsync:SourceGraphQL`

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

**Anmerkung**  
Für das Teilen über AWS RAM muss der Anrufer AWS RAM die Erlaubnis haben, die `appsync:PutResourcePolicy` Aktion auf jeder API auszuführen, die gemeinsam genutzt wird. 

## Zusammenführen
<a name="merges"></a>

### Zusammenführungen verwalten
<a name="managing-merges"></a>

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
<a name="auto-merge"></a>

Die mit Ihrer AWS AppSync zusammengeführten API APIs verknüpfte Quelle kann so konfiguriert werden, dass sie automatisch mit der zusammengeführten API zusammengeführt (Auto-Merge) wird, nachdem Änderungen an der Quell-API vorgenommen wurden. Dadurch wird sichergestellt, dass die Änderungen aus der Quell-API immer im Hintergrund an den Endpunkt der zusammengeführten API weitergegeben werden. Jede Änderung am Quell-API-Schema wird in der zusammengeführten API aktualisiert, sofern dadurch kein Mergekonflikt 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 eingeführt wird, der nicht automatisch gelöst werden kann (automatisch gelöst), wird die Aktualisierung des Schemas der zusammengeführten API aufgrund eines nicht unterstützten Konflikts während des Zusammenführungsvorgangs abgelehnt. Die Fehlermeldung ist in der Konsole für jede Quell-API-Zuordnung 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 Quell-API-Zuordnung mit dem 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>
```

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
<a name="manual-merges"></a>

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

## Zusätzliche Unterstützung für Merged APIs
<a name="merge-api-additional-support"></a>

### Abonnements konfigurieren
<a name="config-subscription"></a>

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 Ihrer zusammengeführten API ohne Änderung. Weitere Informationen darüber, wie Abonnements über serverlose WebSockets Verbindungen AWS AppSync unterstützt werden, finden Sie unter [Echtzeitdaten](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-data.html).

### Beobachtbarkeit konfigurieren
<a name="config-observability"></a>

AWS AppSync APIs Merged bietet integrierte Protokollierung, Überwachung und Metriken über [Amazon CloudWatch](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html). AWS AppSync bietet auch integrierte Unterstützung für die Rückverfolgung über [AWS X-Ray](https://docs.aws.amazon.com/appsync/latest/devguide/x-ray-tracing.html). 

### Konfiguration benutzerdefinierter Domänen
<a name="config-custom-domain"></a>

AWS AppSync APIs Merged bietet integrierte Unterstützung für die Verwendung benutzerdefinierter Domains mit den [GraphQL- und Echtzeit-Endpunkten](https://docs.aws.amazon.com/appsync/latest/devguide/custom-domain-name.html) Ihrer zusammengeführten API. 

### Caching konfigurieren
<a name="config-caching"></a>

AWS AppSync APIs Merged 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.](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html) 

### Private Konfiguration APIs
<a name="config-private-api"></a>

AWS AppSync APIs Merged bietet integrierte Unterstützung für Private APIs , die den Zugriff auf die GraphQL- und Echtzeit-Endpunkte Ihrer zusammengeführten API auf Datenverkehr beschränkt, der von [VPC-Endpunkten stammt, die](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html) Sie konfigurieren können. 

### Konfiguration von Firewall-Regeln
<a name="config-firewall"></a>

AWS AppSync APIs Merged bietet integrierte Unterstützung für AWS WAF, sodass Sie Ihre Daten schützen können, APIs indem Sie [Firewall-Regeln für Webanwendungen](https://docs.aws.amazon.com/appsync/latest/devguide/WAF-Integration.html) definieren. 

### Konfiguration von Audit-Logs
<a name="config-audit"></a>

AWS AppSync APIs Merged bietet integrierte Unterstützung für AWS CloudTrail, mit der Sie [Auditprotokolle konfigurieren und verwalten können](https://docs.aws.amazon.com/appsync/latest/devguide/cloudtrail-logging.html). 

## Einschränkungen bei der zusammengeführten API
<a name="merged-api-limits"></a>

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

1. Eine zusammengeführte API kann keine Quell-API für eine andere zusammengeführte API sein.

1. Eine Quell-API kann nicht mehr als einer zusammengeführten API zugeordnet werden.

1. Die Standardgrößenbeschränkung für ein zusammengeführtes API-Schemadokument beträgt 10 MB.

1. Die Standardanzahl von Quellen APIs , die einer zusammengeführten API zugeordnet werden können, ist 10. Sie können jedoch eine Erhöhung des Limits beantragen, wenn Sie mehr als 10 Quellen APIs in Ihrer zusammengeführten API benötigen.

## Überlegungen zur zusammengeführten API
<a name="merged-api-considerations"></a>

Beachten Sie beim Entwerfen und APIs Implementieren von Merged Folgendes:

Das Zusammenführen mehrerer Quellen 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 die Latenz Ihrer gesamten Anforderungszeit erhöhen kann. Beispielsweise kann es bei einer Abfrage, die auf Felder aus mehreren Quellen zugreift, erforderlich APIs sein AWS AppSync , die Resolver von jeder Quell-API nacheinander auszuführen, wobei jeder Resolver die Gesamtantwortzeit erhöht.

Wir empfehlen Ihnen dringend, Merged während der Entwicklung und unter realistischen Lastbedingungen APIs gründlich zu testen, um sicherzustellen, dass es Ihren Geschäftsanforderungen entspricht. Achten Sie besonders auf:
+ Die Tiefe und Komplexität Ihres zusammengeführten Schemas, insbesondere Abfragen, die auf Felder aus mehreren Quellen zugreifen APIs.
+ Die Anzahl der Resolver, die ausgeführt werden müssen, um gängige Abfragemuster zu erfüllen.
+ Die Leistungsmerkmale Ihrer Datenquellen und Resolver bei erwarteter Last.
+ Die Auswirkungen der Netzwerklatenz beim Zugriff auf Ressourcen aus mehreren Quellen APIs.

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

## Zusammengeführt erstellen APIs
<a name="creating-merged-api"></a>

**Um eine zusammengeführte API in der Konsole zu erstellen**

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AWS AppSync Konsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **Dashboard** **Create API** aus.

1. Wählen Sie „**Zusammengeführte API**“ und anschließend „**Weiter**“.

1. **Geben Sie auf der Seite „API-Details** angeben“ die folgenden Informationen ein: 

   1. Geben Sie unter **API-Details** die folgenden Informationen ein:

      1. Geben Sie den **API-Namen Ihrer zusammengeführten API** an. Dieses Feld ist eine Möglichkeit, Ihre GraphQL-API zu kennzeichnen, um sie bequem von anderen APIs GraphQL zu unterscheiden. 

      1. Geben Sie die **Kontaktdaten an**. Dieses Feld ist optional und fügt der GraphQL-API einen Namen oder eine Gruppe hinzu. Es ist nicht mit anderen Ressourcen verknüpft oder wird von diesen generiert und funktioniert ähnlich wie das API-Namensfeld. 

   1. Unter **Servicerolle** müssen Sie Ihrer zusammengeführten API eine IAM-Ausführungsrolle zuordnen, damit Sie Ihre Ressourcen zur Laufzeit sicher importieren und verwenden AWS AppSync können. Sie können wählen, ob Sie **eine neue Servicerolle erstellen und verwenden** möchten, sodass Sie angeben können, welche Richtlinien und Ressourcen verwendet AWS AppSync werden sollen. Sie können auch eine vorhandene IAM-Rolle importieren, indem Sie „**Bestehende Servicerolle verwenden**“ und dann die Rolle aus der Dropdownliste auswählen. 

   1. Unter **Private API-Konfiguration** können Sie festlegen, ob private API-Funktionen aktiviert werden sollen. Beachten Sie, dass diese Auswahl nach der Erstellung der zusammengeführten API nicht geändert werden kann. Weitere Informationen zu Private APIs finden Sie unter [AWS AppSync Private verwenden APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html). 

      Wählen Sie **Weiter**, wenn Sie fertig sind. 

1. Als Nächstes müssen Sie das GraphQL hinzufügen APIs , das als Grundlage für Ihre zusammengeführte API verwendet wird. Geben Sie auf der APIs Seite **„Quelle auswählen**“ die folgenden Informationen ein: 

   1. Wählen Sie in der Tabelle **APIs Aus Ihrem AWS Konto** die Option **Quelle hinzufügen** aus APIs. In der Liste von GraphQL APIs enthält jeder Eintrag die folgenden Daten:

      1. **Name**: Das API-Namensfeld der **GraphQL-API**. 

      1. **API-ID**: Der eindeutige ID-Wert der GraphQL-API.

      1. **Primärer Authentifizierungsmodus**: Der Standardautorisierungsmodus für die GraphQL-API. Weitere Informationen zu den Autorisierungsmodi finden Sie unter [Autorisierung und Authentifizierung](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html). AWS AppSync

      1. **Zusätzlicher Authentifizierungsmodus**: Die sekundären Autorisierungsmodi, die in der GraphQL-API konfiguriert wurden.

      1. **Wählen Sie den aus APIs , den Sie in der zusammengeführten API verwenden möchten, indem Sie das Kontrollkästchen neben dem Feld Name der API aktivieren.** Wählen Sie anschließend **Quelle hinzufügen APIs**. Das ausgewählte GraphQL APIs wird in der Tabelle **APIs von Ihren AWS Konten** angezeigt.

   1. Wählen Sie in der Tabelle „**APIs Von anderen AWS Konten**“ die Option **Quelle APIs hinzufügen** aus. Die GraphQL APIs in dieser Liste stammen von anderen Konten, die ihre Ressourcen über AWS Resource Access Manager (AWS RAM) mit Ihren teilen. Das Verfahren zur Auswahl von GraphQL APIs in dieser Tabelle ist derselbe wie im vorherigen Abschnitt. Weitere Informationen zur gemeinsamen Nutzung von Ressourcen finden Sie AWS RAM unter [Was ist AWS Resource Access Manager?](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) .

      Wählen Sie **Weiter**, wenn Sie fertig sind.

   1. Fügen Sie Ihren primären Authentifizierungsmodus hinzu. Weitere Informationen finden Sie unter [Autorisierung und Authentifizierung](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html). Wählen Sie **Weiter** aus.

   1. Überprüfe deine Eingaben und wähle dann **Create API** aus.

# GraphQL APIs mit RDS-Introspektion erstellen
<a name="rds-introspection"></a>

AWS AppSync Das Introspection-Hilfsprogramm kann Modelle aus Datenbanktabellen erkennen und GraphQL-Typen vorschlagen. Der Create API Wizard der AWS AppSync Konsole kann sofort eine API aus einer Aurora MySQL- oder PostgreSQL-Datenbank generieren. Er erstellt automatisch Typen und JavaScript Resolver zum Lesen und Schreiben von Daten.

AWS AppSync bietet direkte Integration mit Amazon Aurora Aurora-Datenbanken über die Amazon RDS Data API. Anstatt eine persistente Datenbankverbindung zu benötigen, bietet die Amazon RDS-Daten-API einen sicheren HTTP-Endpunkt, AWS AppSync mit dem eine Verbindung hergestellt wird, um SQL Anweisungen auszuführen. Sie können dies verwenden, um eine relationale Datenbank-API für Ihre MySQL- und PostgreSQL-Workloads auf Aurora zu erstellen.

Das Erstellen einer API für Ihre relationale Datenbank mit hat mehrere Vorteile: AWS AppSync 
+ Ihre Datenbank ist nicht direkt für Clients zugänglich, wodurch der Access Point von der Datenbank selbst entkoppelt wird. 
+ Sie können speziell APIs auf die Bedürfnisse verschiedener Anwendungen zugeschnittene Lösungen erstellen, sodass keine benutzerdefinierte Geschäftslogik in den Frontends erforderlich ist. Dies entspricht dem (BFF- Backend-For-Frontend) Muster. 
+ Autorisierung und Zugriffskontrolle können auf der AWS AppSync Ebene implementiert werden, wobei verschiedene Autorisierungsmodi zur Zugriffskontrolle verwendet werden. Für die Verbindung mit der Datenbank sind keine zusätzlichen Rechenressourcen erforderlich, z. B. das Hosten eines Webservers oder Proxyverbindungen. 
+ Echtzeitfunktionen können über Abonnements hinzugefügt werden, wobei Datenmutationen AppSync automatisch an die verbundenen Clients übertragen werden. 
+ Clients können über HTTPS eine Verbindung zur API herstellen, indem sie gemeinsame Ports wie 443 verwenden.

AWS AppSync macht das Erstellen APIs aus vorhandenen relationalen Datenbanken einfach. Das Introspektionsprogramm kann Modelle aus Datenbanktabellen erkennen und GraphQL-Typen vorschlagen. Der *Create API* Wizard der AWS AppSync Konsole kann sofort eine API aus einer Aurora MySQL- oder PostgreSQL-Datenbank generieren. Er erstellt automatisch Typen und JavaScript Resolver zum Lesen und Schreiben von Daten. 

AWS AppSync bietet integrierte JavaScript Hilfsprogramme, um das Schreiben von SQL-Anweisungen in Resolvern zu vereinfachen. Sie können die AWS AppSync`sql` Tag-Vorlagen für statische Anweisungen mit dynamischen Werten oder die `rds` Modul-Dienstprogramme verwenden, um Anweisungen programmgesteuert zu erstellen. Weitere Informationen finden Sie in der [Resolver-Funktionsreferenz für RDS-Datenquellen](https://docs.aws.amazon.com//appsync/latest/devguide/resolver-reference-rds-js.html) und [integrierte Module](https://docs.aws.amazon.com//appsync/latest/devguide/built-in-modules-js.html#built-in-rds-modules). 

## Verwenden der Introspektionsfunktion (Konsole)
<a name="using-introspection-console"></a>

Ein ausführliches Tutorial und eine Anleitung für die ersten Schritte finden Sie unter [Tutorial: Aurora PostgreSQL Serverless with Data API](https://docs.aws.amazon.com//appsync/latest/devguide/aurora-serverless-tutorial-js.html). 

Mit der AWS AppSync Konsole können Sie in nur wenigen Minuten eine AWS AppSync GraphQL-API aus Ihrer vorhandenen Aurora-Datenbank erstellen, die mit der Daten-API konfiguriert ist. Dadurch wird schnell ein Betriebsschema generiert, das auf Ihrer Datenbankkonfiguration basiert. Sie können die API unverändert verwenden oder darauf aufbauen, um Funktionen hinzuzufügen. 

1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSyncKonsole](https://console.aws.amazon.com/appsync/).

   1. Wählen Sie im **Dashboard** **Create API (API erstellen)** aus.

1. Wählen Sie unter **API-Optionen** **GraphQL APIs**, **Mit einem Amazon Aurora Aurora-Cluster beginnen** und dann **Weiter** aus.

   1. Geben Sie einen **API-Namen** ein. Dieser wird als ID für die API in der Konsole verwendet.

   1. Für **Kontaktinformationen** können Sie eine Kontaktstelle angeben, um einen Manager für die API zu identifizieren. Dies ist ein optionales Feld.

   1. Unter **Private API-Konfiguration** können Sie private API-Funktionen aktivieren. Auf eine private API kann nur von einem konfigurierten VPC-Endpunkt (VPCE) aus zugegriffen werden. [Weitere Informationen finden Sie unter Privat. APIs](https://docs.aws.amazon.com//appsync/latest/devguide/using-private-apis.html)

      Wir empfehlen, diese Funktion für dieses Beispiel nicht zu aktivieren. Wählen Sie „**Weiter**“, nachdem Sie Ihre Eingaben überprüft haben.

1. Wählen Sie auf der **Datenbankseite** die **Option Datenbank auswählen aus**.

   1. Sie müssen Ihre Datenbank aus Ihrem Cluster auswählen. Der erste Schritt besteht darin, die **Region** auszuwählen, in der Ihr Cluster existiert.

   1. Wählen Sie den **Aurora-Cluster** aus der Drop-down-Liste aus. Beachten Sie, dass Sie eine entsprechende Daten-API erstellt und [aktiviert](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/data-api.html#data-api.enabling) haben müssen, bevor Sie die Ressource verwenden können.

   1. Als Nächstes müssen Sie dem Dienst die Anmeldeinformationen für Ihre Datenbank hinzufügen. Dies erfolgt hauptsächlich mit AWS Secrets Manager. Wählen Sie die **Region**, in der Ihr Geheimnis existiert. Weitere Informationen zum Abrufen geheimer Informationen [finden Sie unter Geheimnisse finden](https://docs.aws.amazon.com//secretsmanager/latest/userguide/manage_search-secret.html) oder [Geheimnisse abrufen](https://docs.aws.amazon.com//secretsmanager/latest/userguide/retrieving-secrets.html).

   1. Fügen Sie Ihr Geheimnis aus der Drop-down-Liste hinzu. Beachten Sie, dass der Benutzer über [Leseberechtigungen](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console) für Ihre Datenbank verfügen muss.

1. Wählen Sie **Importieren** aus.

   AWS AppSync beginnt mit der Introspektion Ihrer Datenbank und entdeckt Tabellen, Spalten, Primärschlüssel und Indizes. Es prüft, ob die erkannten Tabellen in einer GraphQL-API unterstützt werden können. Beachten Sie, dass Tabellen zur Unterstützung der Erstellung neuer Zeilen einen Primärschlüssel benötigen, der mehrere Spalten verwenden kann. AWS AppSync ordnet Tabellenspalten wie folgt Typfeldern zu:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/rds-introspection.html)

1. Sobald die Tabellenerkennung abgeschlossen ist, wird der **Datenbankbereich** mit Ihren Informationen gefüllt. Im neuen Abschnitt **Datenbanktabellen** sind die Daten aus der Tabelle möglicherweise bereits aufgefüllt und in einen Typ für Ihr Schema konvertiert. Wenn Sie einige der erforderlichen Daten nicht sehen, können Sie nach ihnen suchen, indem Sie **Tabellen hinzufügen** auswählen, im daraufhin angezeigten Modal auf die Kontrollkästchen für diese Typen klicken und dann **Hinzufügen** auswählen. 

   Um einen Typ aus dem Abschnitt **Datenbanktabellen** zu entfernen, klicken Sie auf das Kontrollkästchen neben dem Typ, den Sie entfernen möchten, und wählen Sie dann **Entfernen**. Die entfernten Typen werden im Modal **Tabellen hinzufügen** platziert, falls Sie sie später wieder hinzufügen möchten.

   Beachten Sie, dass die Tabellennamen als Typnamen AWS AppSync verwendet werden, aber Sie können sie umbenennen, z. B. indem Sie einen Plural-Tabellennamen wie *movies* den Typnamen *Movie* ändern. Um einen Typ im Abschnitt **Datenbanktabellen** umzubenennen, klicken Sie auf das Kontrollkästchen des Typs, den Sie umbenennen möchten, und klicken Sie dann auf das *Stiftsymbol* in der Spalte **Typname**.

   Um eine Vorschau des Schemainhalts auf der Grundlage Ihrer Auswahl anzuzeigen, wählen Sie **Schemavorschau**. Beachten Sie, dass dieses Schema nicht leer sein darf. Sie müssen also mindestens eine Tabelle in einen Typ konvertieren lassen. Außerdem darf dieses Schema eine Größe von 1 MB nicht überschreiten.

   1. Wählen Sie unter **Servicerolle** aus, ob Sie eine neue Servicerolle speziell für diesen Import erstellen oder eine vorhandene Rolle verwenden möchten.

1. Wählen Sie **Weiter** aus.

1. Wählen Sie als Nächstes aus, ob Sie eine schreibgeschützte API (nur Abfragen) oder eine API zum Lesen und Schreiben von Daten (mit Abfragen und Mutationen) erstellen möchten. Letzteres unterstützt auch Echtzeitabonnements, die durch Mutationen ausgelöst werden. 

1. Wählen Sie **Weiter** aus.

1. Überprüfen Sie Ihre Auswahl und wählen Sie dann **Create API**. AWS AppSync erstellt die API und hängt Resolver an Abfragen und Mutationen an. Die generierte API ist voll funktionsfähig und kann nach Bedarf erweitert werden. 

## Verwendung der Introspektionsfunktion (API)
<a name="using-introspection-api"></a>

Sie können die `StartDataSourceIntrospection` Introspektion-API verwenden, um Modelle in Ihrer Datenbank programmgesteuert zu erkennen. Weitere Informationen zu diesem Befehl finden Sie unter Verwenden der API. [https://docs.aws.amazon.com//appsync/latest/APIReference/API_StartDataSourceIntrospection.html](https://docs.aws.amazon.com//appsync/latest/APIReference/API_StartDataSourceIntrospection.html) 

Geben Sie zur Verwendung `StartDataSourceIntrospection` den Amazon-Ressourcennamen (ARN) Ihres Aurora-Clusters, den Datenbanknamen und den AWS Secrets Manager geheimen ARN an. Der Befehl startet den Introspektionsprozess. Sie können die Ergebnisse mit dem `GetDataSourceIntrospection` Befehl abrufen. Sie können angeben, ob der Befehl die SDL-Zeichenfolge (Storage Definition Language) für die erkannten Modelle zurückgeben soll. Dies ist nützlich, um eine SDL-Schemadefinition direkt aus den erkannten Modellen zu generieren.

 Wenn Sie beispielsweise die folgende DDL-Anweisung (Data Definition Language) für eine einfache `Todos` Tabelle haben:

```
create table if not exists public.todos  
(  
id serial constraint todos_pk primary key,  
description text,  
due timestamp,  
"createdAt" timestamp default now()  
);
```

Sie beginnen die Introspektion mit dem Folgenden.

```
aws appsync start-data-source-introspection \ 
  --rds-data-api-config resourceArn=<cluster-arn>,secretArn=<secret-arn>,databaseName=database
```

Verwenden Sie als Nächstes den `GetDataSourceIntrospection` Befehl, um das Ergebnis abzurufen.

```
aws appsync get-data-source-introspection \
  --introspection-id a1234567-8910-abcd-efgh-identifier \
  --include-models-sdl
```

Dies gibt das folgende Ergebnis zurück.

```
{
    "introspectionId": "a1234567-8910-abcd-efgh-identifier",
    "introspectionStatus": "SUCCESS",
    "introspectionStatusDetail": null,
    "introspectionResult": {
        "models": [
            {
                "name": "todos",
                "fields": [
                    {
                        "name": "description",
                        "type": {
                            "kind": "Scalar",
                            "name": "String",
                            "type": null,
                            "values": null
                        },
                        "length": 0
                    },
                    {
                        "name": "due",
                        "type": {
                            "kind": "Scalar",
                            "name": "AWSDateTime",
                            "type": null,
                            "values": null
                        },
                        "length": 0
                    },
                    {
                        "name": "id",
                        "type": {
                            "kind": "NonNull",
                            "name": null,
                            "type": {
                                "kind": "Scalar",
                                "name": "Int",
                                "type": null,
                                "values": null
                            },
                            "values": null
                        },
                        "length": 0
                    },
                    {
                        "name": "createdAt",
                        "type": {
                            "kind": "Scalar",
                            "name": "AWSDateTime",
                            "type": null,
                            "values": null
                        },
                        "length": 0
                    }
                ],
                "primaryKey": {
                    "name": "PRIMARY_KEY",
                    "fields": [
                        "id"
                    ]
                },
                "indexes": [],
                "sdl": "type todos\n{\ndescription: String\n\ndue: AWSDateTime\n\nid: Int!\n\ncreatedAt: AW
SDateTime\n}\n"
            }
        ],
        "nextToken": null
    }
}
```