Verwendung von Abonnements für Echtzeit-Datenanwendungen in AWS AppSync - AWS AppSync

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

AWS AppSyncermöglicht es Ihnen, Abonnements zu verwenden, 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-Schema-Abonnementrichtlinien

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.

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 unterErstellen einer Client-Anwendung mit dem Amplify-Client.

Abonnementargumente verwenden

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 ein auszulösen, subscription wenn ein 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 angebensubscription, 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

Bei einer Abonnementabfrage filtert ein null Argumentwert die Ergebnisse anders AWS AppSync, als wenn das Argument vollständig weggelassen wird.

Kehren wir zum API Todos-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 werdenUpdateTodoInput. 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ügenowner: 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 AWS AppSync APIs verfügbar. Pure WebSockets ist das einzige Protokoll, das in AWS AppSync unterstützt wird.

Clients, die auf den AWS AppSync SDK oder den Amplify-Bibliotheken basieren und nach November 2019 veröffentlicht wurden, verwenden WebSockets standardmäßig automatisch Pure. Wenn Sie die Clients auf die neueste Version aktualisieren, 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 unterAufbau eines Echtzeit-Clients in WebSocket AWS AppSync.