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à.

Utilizzo degli abbonamenti per applicazioni di dati in tempo reale in AWS AppSync

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

Direttive di sottoscrizione dello schema GraphQL

Le sottoscrizioni in AWS AppSync vengono richiamate come risposta a una mutazione. Ciò significa che puoi creare qualsiasi fonte di dati in tempo AWS AppSync reale specificando una direttiva sullo schema GraphQL su 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 client e servizio.

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, puoi 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 abbonamento è necessaria per le connessioni e gli strumenti dei client.

Con il WebSockets client puro, il filtraggio del set di selezione viene eseguito per cliente, poiché ogni cliente 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 la mutazione non includesse l'autore nel set di selezione, il sottoscrittore otterrebbe un null valore per il campo author (o un errore nel caso in cui il campo author sia definito come required/not -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 il tuo schema sia il 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 utilizzando il client Amplify

Utilizzo degli argomenti di sottoscrizione

Una parte importante dell'utilizzo delle sottoscrizioni GraphQL è capire quando e come usare gli argomenti. Puoi apportare lievi modifiche per modificare come e quando notificare ai clienti 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, sono 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 qualsiasi tipo Todo utilizzando l'opzione onUpdateTodo subscription senza argomenti:

subscription OnUpdateTodo {
  onUpdateTodo {
    description
    id
    name
    when
  }
}

Puoi filtrare i tuoi subscription dati utilizzando i relativi argomenti. Ad esempio, per attivare a solo subscription quando ID viene todo aggiornato un valore 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 nella tuasubscription, sarai iscritto a tutti Todo gli aggiornamenti che si verificano 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 tuttitodo:

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

Il valore null dell'argomento ha un significato

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

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

Modifichiamo il nostro schema per includere un nuovo owner campo, nel Todo tipo, che descrive chi è il proprietario. Il owner campo non è obbligatorio e può essere impostato solo suUpdateTodoInput. 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"])
}

La seguente sottoscrizione 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 registra il cliente per ricevere una notifica di tutti gli Todo aggiornamenti che non hanno fornito un proprietario.

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