Dati in tempo reale - AWS AppSync

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Dati in tempo reale

AWS AppSyncconsente di utilizzare gli abbonamenti per implementare aggiornamenti in tempo reale delle applicazioni, notifiche push, ecc. Quando i client richiamano le operazioni di sottoscrizione GraphQL, viene stabilita e gestita automaticamente una connessione WebSocket sicura da. AWS AppSync Le applicazioni possono quindi distribuire i dati in tempo reale da una fonte di dati agli abbonati, gestendo al contempo AWS AppSync i requisiti di connessione e scalabilità dell'applicazione. Le seguenti sezioni ti mostreranno come funzionano gli abbonamenti. AWS AppSync

Direttive di sottoscrizione allo schema GraphQL

Le sottoscrizioni in AWS AppSync vengono richiamate come risposta a una mutazione. Questo significa che puoi rendere qualsiasi origine dati AWS AppSync un elemento in tempo reale specificando una direttiva dello schema GraphQL in una mutazione.

Le librerie AWS Amplify client gestiscono automaticamente la gestione delle connessioni in abbonamento. Le librerie utilizzano pure WebSockets come protocollo di rete tra il client e il servizio.

Nota

Per controllare l'autorizzazione al momento della connessione a un abbonamento, puoi utilizzare AWS Identity and Access Management (IAM)AWS Lambda, i pool di identità di Amazon Cognito o i pool di utenti Amazon Cognito per l'autorizzazione a livello di campo. Per i controlli degli accessi granulari nelle sottoscrizioni, puoi collegare resolver ai campi della sottoscrizione ed eseguire la logica tramite l'identità del chiamante e origini dati AWS AppSync . Per ulteriori informazioni, consulta Autorizzazione e autenticazione.

Le sottoscrizioni vengono attivate da mutazioni e il set di selezioni delle mutazioni viene inviato ai sottoscrittori.

L'esempio seguente mostra come usare sottoscrizioni GraphQL. Non specifica un'origine dati perché l'origine dati potrebbe essere Lambda, Amazon DynamoDB o Amazon Service. OpenSearch

Per iniziare con gli abbonamenti, devi aggiungere un punto di ingresso dell'abbonamento allo schema come segue:

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

Supponiamo di avere un sito di post di blog e di voler sottoscrivere nuovi blog e le modifiche a blog esistenti. A questo scopo, aggiungere la definizione Subscription seguente allo schema:

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

Supponiamo inoltre di avere le mutazioni seguenti:

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

Puoi impostare questi campi come elementi in tempo reale aggiungendo una direttiva @aws_subscribe(mutations: ["mutation_field_1", "mutation_field_2"]) per ognuna delle sottoscrizioni per cui vuoi ricevere notifiche, in questo modo:

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

Poiché @aws_subscribe(mutations: ["",..,""]) richiede una serie di input di mutazione, è possibile specificare più mutazioni, che avviano una sottoscrizione. Se esegui la sottoscrizione da un client, la query GraphQL può essere simile alla seguente:

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

Questa richiesta di sottoscrizione è necessaria per le connessioni e gli strumenti dei client.

Con il WebSockets client puro, il filtraggio del set di selezione viene eseguito per client, poiché ogni client può definire il proprio set di selezione. In questo caso, il set di selezione della sottoscrizione deve essere un sottoinsieme del set di selezione delle mutazioni. Ad esempio, un abbonamento addedPost{author title} collegato alla mutazione addPost(...){id author title url version} riceve solo l'autore e il titolo del post. Non riceve gli altri campi. Tuttavia, se per la mutazione manca l'autore nel set di selezione, il sottoscrittore ottiene un valore null per il campo autore (o un errore nel caso in cui il campo autore sia definito come richiesto/non-null nello schema).

Il set di selezione dell'abbonamento è essenziale quando si utilizza pure WebSockets. Se un campo non è definito in modo esplicito nell'abbonamento, AWS AppSync non restituisce il campo.

Nell'esempio precedente, le sottoscrizioni non dispongono di argomenti. Supponiamo che lo schema sia simile al seguente:

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

In questo caso, il client definisce una sottoscrizione come segue:

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

Il tipo restituito di un campo subscription nello schema deve corrispondere al tipo restituito del campo della mutazione corrispondente. Questo è stato mostrato nell'esempio precedente, in quanto sia addPost sia addedPost hanno restituito Post come tipo.

Per configurare gli abbonamenti sul client, consulta. Creazione di un'applicazione client

Utilizzo degli argomenti di sottoscrizione

Una parte importante dell'utilizzo degli abbonamenti GraphQL è capire quando e come utilizzare gli argomenti. È possibile apportare lievi modifiche per modificare come e quando notificare ai client le mutazioni che si sono verificate. A tale scopo, consultate lo schema di esempio tratto dal capitolo quickstart, che crea «Todos». Per questo schema di esempio, vengono definite le seguenti mutazioni:

type Mutation { createTodo(input: CreateTodoInput!): Todo updateTodo(input: UpdateTodoInput!): Todo deleteTodo(input: DeleteTodoInput!): Todo }

Nell'esempio predefinito, i client possono sottoscrivere gli aggiornamenti di any Todo utilizzando il comando onUpdateTodo subscription senza argomenti:

subscription OnUpdateTodo { onUpdateTodo { description id name when } }

Puoi filtrare i tuoi subscription utilizzando i relativi argomenti. Ad esempio, per attivare a solo subscription quando ID viene aggiornato un todo con uno specifico, specifica il ID valore:

subscription OnUpdateTodo { onUpdateTodo(id: "a-todo-id") { description id name when } }

Puoi anche passare più argomenti. Ad esempio, quanto segue subscription dimostra come ricevere notifiche di eventuali Todo aggiornamenti in un luogo e in un'ora specifici:

subscription todosAtHome { onUpdateTodo(when: "tomorrow", where: "at home") { description id name when where } }

Nota che tutti gli argomenti sono opzionali. Se non specifichi alcun argomento nel tuosubscription, sarai iscritto a tutti Todo gli aggiornamenti che avvengono nella tua applicazione. Tuttavia, puoi aggiornare la definizione subscription del campo per richiedere l'IDargomento. Ciò forzerebbe la risposta di uno specifico todo anziché di tutti i todo s:

onUpdateTodo( id: ID!, name: String, when: String, where: String, description: String ): Todo

Il valore null dell'argomento ha un significato

Quando esegui una query di sottoscrizione in AWS AppSync, un valore di argomento null filtrerà i risultati in modo diverso rispetto all'omissione dell'argomento.

Torniamo all'esempio di API todos in cui potremmo creare todos. Vedi lo schema di esempio tratto dal capitolo quickstart.

Modifichiamo il nostro schema per includere un nuovo owner campo, sul Todo tipo, che descriva chi è il proprietario. Il owner campo non è obbligatorio e può essere solo impostatoUpdateTodoInput. Vedi la seguente versione semplificata dello schema:

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"]) }

Il seguente abbonamento restituisce tutti gli Todo aggiornamenti:

subscription MySubscription { onUpdateTodo { description id name when where } }

Se modifichi la sottoscrizione precedente per aggiungere l'argomento del campoowner: null, ora stai facendo una domanda diversa. Questo abbonamento ora consente al cliente di ricevere una notifica di tutti gli Todo aggiornamenti per i quali non è stato fornito alcun proprietario.

subscription MySubscription { onUpdateTodo(owner: null) { description id name when where } }
Nota

A partire dal 1° gennaio 2022, MQTT over non WebSockets è più disponibile come protocollo per gli abbonamenti AWS AppSync GraphQL nelle API. Pure WebSockets è l'unico protocollo supportato in. AWS AppSync

I client basati sull'AWS AppSyncSDK o sulle librerie Amplify, rilasciati dopo novembre 2019, utilizzano automaticamente pure per impostazione predefinita. WebSockets L'aggiornamento dei client alla versione più recente consente loro di utilizzare il motore puro. AWS AppSync WebSockets

Pure offre una dimensione del payload più grande (240 KB), una più ampia varietà di opzioni client e metriche WebSockets migliorate. CloudWatch Per ulteriori informazioni sull'utilizzo dei WebSocket client pure, consulta. WebSocket Creazione di un client in tempo reale