

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.

# 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).