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 delle operazioni Delta Sync su sorgenti dati con versione in AWS AppSync
**Nota**
Ora supportiamo principalmente il runtime APPSYNC\$1JS e la relativa documentazione. [Prendi in considerazione l'utilizzo del runtime APPSYNC\$1JS e delle relative guide qui.](https://docs.aws.amazon.com/appsync/latest/devguide/tutorials-js.html)
Le applicazioni client AWS AppSync archiviano i dati memorizzando nella cache le risposte GraphQL localmente sul disco di 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 la tua 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.](https://aws-amplify.github.io/) 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
[https://console.aws.amazon.com/cloudformation/home?region=us-west-2#/stacks/new?templateURL=https://s3.us-west-2.amazonaws.com/awsappsync/resources/deltasync/deltasync-v2-full.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-west-2#/stacks/new?templateURL=https://s3.us-west-2.amazonaws.com/awsappsync/resources/deltasync/deltasync-v2-full.yaml)
Con questo stack. nell'account vengono create le seguenti risorse:
+ 2 tabelle DynamoDB (Base e Delta)
+ 1 AWS AppSync API con chiave API
+ 1 ruolo IAM 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) DynamoDB viene utilizzato per organizzare automaticamente gli eventi in base alle necessità. L'ora TTL è configurabile per le tue esigenze sull'origine dati (puoi impostarla 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 passa in `lastSync: AWSTimestamp`, la query `syncPosts` viene eseguita sulla tabella *Base* per rigenerare la cache e, periodicamente, come *procedura di aggiornamento globale*, per i casi limite in cui i client restano offline più a lungo rispetto alla tempistica di TTL configurata 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 *\$1deleted* su *Post* viene utilizzato per 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'Create/Update/Deleteoperazione standard 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](aws-appsync-conflict-detection-and-sync-sync-operations.md).
## 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:
1. Un record al momento della creazione dell'elemento
1. 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
}
}
}
```