Données en temps réel - AWS AppSync

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Données en temps réel

Directives d'abonnement au schéma GraphQL

Les abonnements dans AWS AppSync sont appelés en tant que réponse à une mutation. Cela signifie que vous pouvez transformer n'importe quelle source de données dans AWS AppSync en source de données en temps réel, en spécifiant une directive de schéma GraphQL lors d'une mutation.

LeAWS Amplifyles bibliothèques clientes gèrent automatiquement la gestion des connexions d'abonnement. Les bibliothèques utilisent du pur WebSockets en tant que protocole réseau entre le client et le service.

Remarque : Pour contrôler l'autorisation au moment de la connexion à un abonnement, vous pouvez utiliserAWS Identity and Access Management(OBJECTIF),AWS Lambda, des groupes d'identités Amazon Cognito ou des groupes d'utilisateurs Amazon Cognito pour l'autorisation au niveau du champ. Pour le contrôle précis des accès sur les abonnements, vous pouvez attacher des résolveurs à vos champs d'abonnement et appliquer une logique en utilisant l'identité de l'appelant et les sources de données AWS AppSync . Pour plus d'informations, consultez Autorisation et authentification.

Les abonnements sont déclenchés à partir des mutations et le jeu de sélection de mutations est envoyé aux abonnés.

L'exemple suivant montre comment utiliser les abonnements GraphQL. Il ne spécifie pas de source de données, car la source de données pourrait être Lambda, Amazon DynamoDB ou Amazon OpenSearch Service.

Pour commencer avec les abonnements, vous devez ajouter un point d'entrée d'abonnement à votre schéma, comme suit :

schema { query: Query mutation: Mutation subscription: Subscription }

Supposons que vous disposez d'un site de blog et que vous souhaitez vous abonner à de nouveaux blogs et à des modifications de blogs existants. Pour ce faire, vous devez ajouter la définition Subscription suivante à votre schéma :

type Subscription { addedPost: Post updatedPost: Post deletedPost: Post }

Supposons encore que vous disposez des mutations suivantes :

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! }

Vous pouvez transformer ces champs en temps réel en ajoutant une directive @aws_subscribe(mutations: ["mutation_field_1", "mutation_field_2"]) pour chacun des abonnements pour lesquels vous souhaitez recevoir des notifications, comme suit :

type Subscription { addedPost: Post @aws_subscribe(mutations: ["addPost"]) updatedPost: Post @aws_subscribe(mutations: ["updatePost"]) deletedPost: Post @aws_subscribe(mutations: ["deletePost"]) }

Etant donné que le@aws_subscribe(mutations: ["",..,""])prend un tableau d'entrées de mutation, vous pouvez spécifier plusieurs mutations, qui initient un abonnement. Si vous vous abonnez à partir d'un client, votre requête GraphQL peut ressembler à ce qui suit :

subscription NewPostSub { addedPost { __typename version title content author url } }

Cette requête d'abonnement est nécessaire pour les outils et les connexions client.

Avec le pur WebSockets client, jeu de sélection, le filtrage est effectué par client, car chaque client peut définir son propre jeu de sélection. Dans ce cas, le jeu de sélection d'abonnement doit être un sous-ensemble du jeu de sélection de mutation. Par exemple, un abonnementaddedPost{author title}lié à la mutationaddPost(...){id author title url version}reçoit uniquement l'auteur et le titre du message. Il ne reçoit pas les autres champs. Cependant, si la mutation n'avait pas l'auteur dans son ensemble de sélection, l'abonné obtiendrait une valeur null pour le champ auteur (ou une erreur dans le cas où le champ auteur est défini comme « required/not-null » dans le schéma).

Le kit de sélection des abonnements est essentiel lors de l'utilisation de pure WebSockets. Si un champ n'est pas explicitement défini dans l'abonnement, alorsAWS AppSyncne retourne pas le champ.

Dans l'exemple précédent, les abonnements n'avaient pas d'arguments. Imaginez que votre schéma se présente comme suit :

type Subscription { updatedPost(id:ID! author:String): Post @aws_subscribe(mutations: ["updatePost"]) }

Dans ce cas, votre client définit un abonnement ainsi :

subscription UpdatedPostSub { updatedPost(id:"XYZ", author:"ABC") { title content } }

Le type de retour d'un champ subscription dans votre schéma doit correspondre au type de retour du champ de mutation correspondant. L'exemple précédent illustrait cela avec addPost et addedPost qui ont été renvoyés en tant que type de Post.

Pour configurer des abonnements sur le client, consultezCréation d'une application cliente.

Utilisation d'arguments d'abonnement

Une part importante de l'utilisation des abonnements GraphQL consiste à comprendre quand et comment utiliser les arguments. Vous pouvez apporter des modifications subtiles pour modifier comment et quand informer les clients des mutations survenues. Pour ce faire, consultez l'exemple de schéma deLancement d'un exemple de schéma, qui crée des « Événements » et des « Commentaires ». Pour cet exemple de schéma, la mutation suivante survient :

type Mutation { createEvent( name: String!, when: String!, where: String!, description: String! ): Event deleteEvent(id: ID!): Event commentOnEvent(eventId: ID!, content: String!, createdAt: String!): Comment }

Dans l'exemple par défaut, les clients peuvent s'abonner aux Commentaires lorsqu'un argument eventId spécifique est transmis :

type Subscription { subscribeToEventComments(eventId: String!): Comment @aws_subscribe(mutations: ["commentOnEvent"]) }

Toutefois, si vous voulez permettre aux clients de s'abonner à un événement unique OU à tous les événements, vous pouvez rendre cet argument facultatif en supprimant le point d'exclamation (!) dans le prototype d'abonnement :

subscribeToEventComments(eventId: String): Comment

Grâce à cette modification, les clients qui ont omis cet argument peuvent obtenir des commentaires pour tous les événements. De plus, si vous voulez que les clients s'abonnent explicitement à tous les commentaires pour tous les événements, vous devez supprimer l'argument :

subscribeToEventComments: Comment

Utilisez ceux-ci est pour des commentaires sur un ou plusieurs événements. Si vous voulez tout savoir concernant tous les événements qui sont créés, vous pouvez effectuer les opérations suivantes :

type Subscription { subscribeToNewEvents: Event @aws_subscribe(mutations: ["createEvent"]) }

Plusieurs arguments peuvent également être transmis. Par exemple, si vous voulez être averti des nouveaux événements à un endroit et un moment spécifiques, procédez comme suit :

type Subscription { subscribePlaceDate(where: String! when: String!): Event @aws_subscribe(mutations: ["createEvent"]) }

Ainsi, l'application cliente peut maintenant faire ce qui suit :

subscription myplaces { subscribePlaceDate(where: "Seattle" when: "Saturday"){ id name description } }

La valeur null de l'argument a une signification

Lorsque vous effectuez une requête d'abonnement dans AWS AppSync, une valeur d'argument null filtre les résultats différemment de l'omission complète de l'argument.

Revenons à l'exemple d'application d'événements où nous pouvons créer des événements et publier des commentaires sur les événements. Voir l'exemple de schéma deLancement d'un exemple de schéma.

Modifiez notre schéma pour inclure un nouveaulocationsur le terrain, sur leCommentchamp, qui décrit d'où le commentaire a été envoyé. La valeur peut être un ensemble de coordonnées ou un lieu. Reportez-vous au schéma suivant, simplifié par souci de concision :

type Comment { # The id of the comment's parent event. eventId: ID! # A unique identifier for the comment. commentId: String! # The comment's content. content: String # Location where the comment was made location: String } type Event { id: ID! name: String where: String when: String description: String } type Mutation { commentOnEvent(eventId: ID!, location: String, content: String): Comment } type Subscription { subscribeToEventComments(eventId: String!, location: String, content: String): Comment @aws_subscribe(mutations: ["commentOnEvent"]) }

Vous pouvez remarquer le nouveau champ facultatif Comment.location.

Imaginez maintenant que nous voulons recevoir des notifications pour tous les commentaires lorsqu'ils sont publiés pour un événement particulier. Dans ce cas, nous écrirons l'abonnement suivant :

subscribeToEventComments(eventId: "1") { eventId commentId location content }

Si nous ajoutons plutôt l'argument de champlocation: nullà l'abonnement précédent :

subscribeToEventComments(eventId: "1" location: null) { eventId commentId location content }

Nous posons une autre question. Cet abonnement enregistre désormais le client pour être informé de tous les commentaires qui n'ont pas fourni de lieu pour un événement particulier.

Note

À compter du 1er janvier 2022, le MQTT est terminé WebSockets n'est plus disponible en tant que protocole pour les abonnements GraphQL dansAWS AppSyncAPIs. Pur WebSockets est le seul protocole pris en charge dansAWS AppSync.

Des clients basés surAWS AppSyncLe SDK ou les bibliothèques Amplify, publiés après novembre 2019, utilisent automatiquement pure WebSockets par défaut. La mise à niveau des clients vers la dernière version leur permet d'utiliserAWS AppSyncest pur WebSockets moteur.

Pur WebSockets sont dotés d'une charge utile plus importante (240 Ko), d'une plus grande variété d'options clients et d'une CloudWatch métriques , Pour plus d'informations sur l'utilisation de Pure WebSocket clients, voirCréation d'une WebSocket client.