Impostazione One-Click Schema Mutazioni Query di sincronizzazione Esempio

Tutorial: Utilizzo delle operazioni Delta Sync su fonti di dati con versioni

Nota

Ora supportiamo principalmente il runtime APPSYNC _JS e la relativa documentazione. Valuta la possibilità di utilizzare il runtime APPSYNC _JS e le relative guide qui.

Le applicazioni client AWS AppSync archiviano i dati memorizzando nella cache le risposte GraphQL localmente su disco in un'applicazione mobile/web. Le origini dati e le operazioni Sync con versioni offrono ai clienti la possibilità di eseguire il processo di sincronizzazione utilizzando un unico resolver. In tal modo, per i client è possibile rigenerare la cache locale con i risultati della query di base, dalla notevole quantità di record, per poi acquisire solo i dati variati dall'ultima query (gli aggiornamenti differenziali). Consentendo ai client di eseguire la rigenerazione di base della cache con una richiesta iniziale e con aggiornamenti incrementali con una seconda richiesta, è possibile trasferire le risorse e le operazioni di calcolo dall'applicazione client al back-end. Ciò è sostanzialmente più efficiente per le applicazioni client che spesso passano da uno stato online a uno stato offline.

Per implementare Delta Sync, la query Sync utilizza l'operazione Sync su un'origine dati con versione. Quando una AWS AppSync mutazione modifica un elemento in un'origine dati con versione, un record di tale modifica verrà archiviato anche nella tabella Delta. Puoi scegliere di utilizzare diverse tabelle Delta (ad esempio una per tipo, una per area di dominio) per altre fonti di dati con versione o una singola tabella Delta per le tue. API AWS AppSync sconsiglia di utilizzare una singola tabella Delta per più tabelle per APIs evitare la collisione delle chiavi primarie.

Inoltre, i client che si avvalgono della sincronizzazione differenziale possono ricevere una sottoscrizione sotto forma di argomento, per poi coordinarne le operazioni di scrittura e riconnessione nelle transizioni tra offline e online. A tale scopo, la sincronizzazione automatica riprende automaticamente le sottoscrizioni, inclusa una strategia di "backoff esponenziale e riprova con jitter" su più scenari di errore di rete e archivia gli eventi in una coda. Esegue poi, prima dell'unione degli eventi in coda, la query di base o differenziale appropriata e, infine, elabora le sottoscrizioni normalmente.

La documentazione per le opzioni di configurazione del client, incluso Amplify, è disponibile sul sito Web di DataStore Amplify Framework. Questa documentazione illustra come impostare origini dati e operazioni Sync DynamoDB con versioni per lavorare con il client Delta Sync per un accesso ottimale ai dati.

Impostazione One-Click

Per configurare automaticamente l'endpoint GraphQL AWS AppSync con tutti i resolver configurati e le risorse necessarie AWS , usa questo modello: AWS CloudFormation

Con questo stack. nell'account vengono create le seguenti risorse:

2 tabelle DynamoDB (Base e Delta)
1 AWS AppSync API con chiave API
1 IAM Ruolo con policy per le tabelle DynamoDB

Due tabelle tornano utili per partizionare le query di sincronizzazione differenziali in una seconda tabella che funge da registro degli eventi non rilevati con i client offline. Per mantenere efficienti le query sulla tabella delta, TTLsAmazon DynamoDB viene utilizzato per organizzare automaticamente gli eventi in base alle necessità. L'TTLorario è configurabile in base alle tue esigenze sulla fonte di dati (potresti volerlo come 1 ora, 1 giorno, ecc.).

Schema

Per dimostrare Delta Sync, l'applicazione di esempio crea uno schema Posts supportato da una tabella Base e Delta in DynamoDB. AWS AppSync scrive automaticamente le mutazioni in entrambe le tabelle. Le query di sincronizzazione estraggono i record dalla tabella Base o Delta, in base alle esigenze, e viene definita un'unica sottoscrizione che mostra in che modo i client possono avvalersene nella propria logica di riconnessione.


input CreatePostInput {
    author: String!
    title: String!
    content: String!
    url: String
    ups: Int
    downs: Int
    _version: Int
}

interface Connection {
  nextToken: String
  startedAt: AWSTimestamp!
}

type Mutation {
    createPost(input: CreatePostInput!): Post
    updatePost(input: UpdatePostInput!): Post
    deletePost(input: DeletePostInput!): Post
}

type Post {
    id: ID!
    author: String!
    title: String!
    content: String!
    url: AWSURL
    ups: Int
    downs: Int
    _version: Int
    _deleted: Boolean
    _lastChangedAt: AWSTimestamp!
}

type PostConnection implements Connection {
    items: [Post!]!
    nextToken: String
    startedAt: AWSTimestamp!
}

type Query {
    getPost(id: ID!): Post
    syncPosts(limit: Int, nextToken: String, lastSync: AWSTimestamp): PostConnection!
}

type Subscription {
    onCreatePost: Post
        @aws_subscribe(mutations: ["createPost"])
    onUpdatePost: Post
        @aws_subscribe(mutations: ["updatePost"])
    onDeletePost: Post
        @aws_subscribe(mutations: ["deletePost"])
}

input DeletePostInput {
    id: ID!
    _version: Int!
}

input UpdatePostInput {
    id: ID!
    author: String
    title: String
    content: String
    url: String
    ups: Int
    downs: Int
    _version: Int!
}

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

Lo schema di GraphQL è standard, tuttavia conviene soffermarsi su un paio di aspetti, prima di procedere. Innanzitutto, tutte le mutazioni scrivono automaticamente prima nella tabella Base e poi nella tabella Delta. La tabella Base è la fonte centrale di attendibilità per lo stato, mentre la Differenziale funge da registro. Se non si trasmette illastSync: AWSTimestamp, la syncPosts query viene eseguita sulla tabella Base e idrata la cache, oltre a essere eseguita a intervalli regolari come processo di recupero globale per i casi limite in cui i client sono offline per un periodo più lungo del TTL tempo configurato nella tabella Delta. Se si passa in lastSync: AWSTimestamp, la query syncPosts viene eseguita sulla tabella Delta e viene utilizzata dai client per recuperare gli eventi cambiati dall'ultimo passaggio offline. L'amplificazione dei client passa automaticamente il valore lastSync: AWSTimestamp e persiste sul disco in modo appropriato.

Il campo _deleted su Post viene utilizzato per le operazioni. DELETE Quando i client sono offline e i record vengono rimossi dalla tabella Base, questo attributo notifica ai client l'eliminazione delle voci dalla cache locale in fase di sincronizzazione. Se i client restano offline per un periodo prolungato e la voce viene rimossa prima che si possa recuperare questo valore con una query di sincronizzazione differenziale, l'evento di aggiornamento globale nella query di base (configurabile nel client) viene eseguito e rimuove la voce dalla cache. Questo campo viene contrassegnato come facoltativo perché restituisce un valore solo all'esecuzione di una query di sincronizzazione responsabile dell'eliminazione di elementi.

Mutazioni

Per tutte le mutazioni, AWS AppSync esegue un'operazione standard di creazione/aggiornamento/eliminazione nella tabella Base e registra automaticamente anche la modifica nella tabella Delta. È possibile ridurre o estendere il tempo di permanenza dei record, modificando il valore DeltaSyncTableTTL nell'origine dati. Alle organizzazioni che acquisiscono ed elaborano dati frequentemente e rapidamente si addice un periodo di permanenza ridotto. Se invece i client restano offline a lungo, è consigliabile impostare un periodo di permanenza prolungato.

Query di sincronizzazione

La query di base è un'operazione di sincronizzazione DynamoDB senza lastSync un valore specificato. Lo standard torna utile a quelle organizzazioni che eseguono la query di base solo all'avvio e, successivamente, a cadenza periodica.

La delta query è un'operazione di sincronizzazione DynamoDB con lastSync un valore specificato. La query delta viene eseguita ogni volta che il client torna online da uno stato offline (se le tempistiche per le attività periodiche della query di base non hanno avviato l'esecuzione). I client monitorano automaticamente l'ultima volta che hanno eseguito correttamente una query per sincronizzare i dati.

Quando viene eseguita una query delta, il resolver della query utilizza ds_pk e ds_sk per eseguire query solo per i record che sono stati modificati dall'ultima volta che il client ha eseguito una sincronizzazione. Il client memorizza nella cache la risposta di GraphQL appropriata.

Per ulteriori informazioni sull'esecuzione di query di sincronizzazione, vedere la documentazione relativa all'operazione di sincronizzazione.

Esempio

Iniziamo prima chiamando una mutazione createPost per creare un elemento:


mutation create {
  createPost(input: {author: "Nadia", title: "My First Post", content: "Hello World"}) {
    id
    author
    title
    content
    _version
    _lastChangedAt
    _deleted
  }
}

Il valore di restituzione di questa mutazione sarà il seguente:


{
  "data": {
    "createPost": {
      "id": "81d36bbb-1579-4efe-92b8-2e3f679f628b",
      "author": "Nadia",
      "title": "My First Post",
      "content": "Hello World",
      "_version": 1,
      "_lastChangedAt": 1574469356331,
      "_deleted": null
    }
  }
}

Se si esamina il contenuto della tabella Base si vedrà un record simile a:


{
  "_lastChangedAt": {
    "N": "1574469356331"
  },
  "_version": {
    "N": "1"
  },
  "author": {
    "S": "Nadia"
  },
  "content": {
    "S": "Hello World"
  },
  "id": {
    "S": "81d36bbb-1579-4efe-92b8-2e3f679f628b"
  },
  "title": {
    "S": "My First Post"
  }
}

Se si esamina il contenuto della tabella Delta si vedrà un record simile a:


{
  "_lastChangedAt": {
    "N": "1574469356331"
  },
  "_ttl": {
    "N": "1574472956"
  },
  "_version": {
    "N": "1"
  },
  "author": {
    "S": "Nadia"
  },
  "content": {
    "S": "Hello World"
  },
  "ds_pk": {
    "S": "AppSync-delta-sync-post:2019-11-23"
  },
  "ds_sk": {
    "S": "00:35:56.331:81d36bbb-1579-4efe-92b8-2e3f679f628b:1"
  },
  "id": {
    "S": "81d36bbb-1579-4efe-92b8-2e3f679f628b"
  },
  "title": {
    "S": "My First Post"
  }
}

Ora possiamo simulare una query di base che un client eseguirà per rigenerare il suo archivio dati locale utilizzando una query syncPosts come:


query baseQuery {
  syncPosts(limit: 100, lastSync: null, nextToken: null) {
    items {
      id
      author
      title
      content
      _version
      _lastChangedAt
    }
    startedAt
    nextToken
  }
}

Il valore restituito di questa query di base sarà il seguente:


{
  "data": {
    "syncPosts": {
      "items": [
        {
          "id": "81d36bbb-1579-4efe-92b8-2e3f679f628b",
          "author": "Nadia",
          "title": "My First Post",
          "content": "Hello World",
          "_version": 1,
          "_lastChangedAt": 1574469356331
        }
      ],
      "startedAt": 1574469602238,
      "nextToken": null
    }
  }
}

Salveremo il valore startedAt in seguito per simulare una query Delta, ma prima dobbiamo apportare una modifica alla nostra tabella. Usiamo la mutazione updatePost per modificare il nostro Post esistente:


mutation updatePost {
  updatePost(input: {id: "81d36bbb-1579-4efe-92b8-2e3f679f628b", _version: 1, title: "Actually this is my Second Post"}) {
    id
    author
    title
    content
    _version
    _lastChangedAt
    _deleted
  }
}

Il valore di restituzione di questa mutazione sarà il seguente:


{
  "data": {
    "updatePost": {
      "id": "81d36bbb-1579-4efe-92b8-2e3f679f628b",
      "author": "Nadia",
      "title": "Actually this is my Second Post",
      "content": "Hello World",
      "_version": 2,
      "_lastChangedAt": 1574469851417,
      "_deleted": null
    }
  }
}

Se esamini il contenuto della tabella Base ora, dovresti vedere l'elemento aggiornato:


{
  "_lastChangedAt": {
    "N": "1574469851417"
  },
  "_version": {
    "N": "2"
  },
  "author": {
    "S": "Nadia"
  },
  "content": {
    "S": "Hello World"
  },
  "id": {
    "S": "81d36bbb-1579-4efe-92b8-2e3f679f628b"
  },
  "title": {
    "S": "Actually this is my Second Post"
  }
}

Se esamini il contenuto della tabella Delta ora, dovresti vedere due record:

Un record al momento della creazione dell'elemento
Un record per quando l'elemento è stato aggiornato.

Il nuovo elemento sarà simile a:


{
  "_lastChangedAt": {
    "N": "1574469851417"
  },
  "_ttl": {
    "N": "1574473451"
  },
  "_version": {
    "N": "2"
  },
  "author": {
    "S": "Nadia"
  },
  "content": {
    "S": "Hello World"
  },
  "ds_pk": {
    "S": "AppSync-delta-sync-post:2019-11-23"
  },
  "ds_sk": {
    "S": "00:44:11.417:81d36bbb-1579-4efe-92b8-2e3f679f628b:2"
  },
  "id": {
    "S": "81d36bbb-1579-4efe-92b8-2e3f679f628b"
  },
  "title": {
    "S": "Actually this is my Second Post"
  }
}

Ora possiamo simulare una query Delta per recuperare le modifiche che si sono verificate quando il client era offline. Useremo il valore startedAt restituito dalla nostra query di base per fare la richiesta:


query delta {
  syncPosts(limit: 100, lastSync: 1574469602238, nextToken: null) {
    items {
      id
      author
      title
      content
      _version
    }
    startedAt
    nextToken
  }
}

Il valore restituito di questa query Delta sarà il seguente:


{
  "data": {
    "syncPosts": {
      "items": [
        {
          "id": "81d36bbb-1579-4efe-92b8-2e3f679f628b",
          "author": "Nadia",
          "title": "Actually this is my Second Post",
          "content": "Hello World",
          "_version": 2
        }
      ],
      "startedAt": 1574470400808,
      "nextToken": null
    }
  }
}

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Tutorial: utilizzo dei resolver di pipeline in AWS AppSync

Configurazione e impostazioni