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.

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

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 von hergestellt und aufrechterhalten. 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.

Abonnementrichtlinien für GraphQL-Schemas

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 übernehmen automatisch die Abonnementverbindungsverwaltung. Die Bibliotheken verwenden Pure WebSockets als Netzwerkprotokoll zwischen dem Client und dem Dienst.

Abonnements werden durch Mutationen ausgelöst und die Mutationsauswahlmenge wird an Abonnenten gesendet.

Das folgende Beispiel zeigt, wie Sie mit GraphQL-Abonnements arbeiten. Es wird keine Datenquelle angegeben, 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, die ein Abonnement initiieren. 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. Fehlt bei der Mutation jedoch der Autor in ihrem Auswahlsatz, würde der Abonnent einen null Wert für das Autorenfeld erhalten (oder einen Fehler, falls das Autorenfeld im Schema als required/not -null definiert ist).

Der Abonnement-Auswahlsatz ist unerlässlich, wenn Sie Pure verwenden. 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.

Verwenden von Abonnement-Argumenten

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 Kunden ü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 die Option onUpdateTodo subscription ohne Argumente verwenden:

subscription OnUpdateTodo {
  onUpdateTodo {
    description
    id
    name
    when
  }
}

Sie können Ihre subscription anhand ihrer Argumente filtern. Um beispielsweise nur dann ein auszulösen, subscription wenn ein todo mit einem bestimmten aktualisiert ID wird, geben Sie den 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 subscription veranschaulicht, wie Sie an einem bestimmten Ort und zu einer bestimmten Uhrzeit Todo über Aktualisierungen informiert 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 vorkommen. Sie könnten jedoch Ihre Felddefinition subscription so aktualisieren, dass das ID Argument erforderlich 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

Wenn Sie eine Abonnementabfrage stellen AWS AppSync, filtert ein null Argumentwert die Ergebnisse anders, 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 Besitzer 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 den Client jetzt, 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
  }
}