Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Menggunakan operasi Delta Sync pada sumber data berversi di AWS AppSync
<a name="tutorial-delta-sync"></a>

**catatan**  
Kami sekarang terutama mendukung runtime APPSYNC\$1JS dan dokumentasinya. [Harap pertimbangkan untuk menggunakan runtime APPSYNC\$1JS dan panduannya di sini.](https://docs.aws.amazon.com/appsync/latest/devguide/tutorials-js.html)

Aplikasi klien dalam AWS AppSync menyimpan data dengan menyimpan respons GraphQL secara lokal ke disk dalam aplikasi. mobile/web Sumber dan `Sync` operasi data berversi memberi pelanggan kemampuan untuk melakukan proses sinkronisasi menggunakan resolver tunggal. Ini memungkinkan klien untuk menghidrasi cache lokal mereka dengan hasil dari satu kueri dasar yang mungkin memiliki banyak catatan, dan kemudian hanya menerima data yang diubah sejak kueri terakhir mereka (pembaruan *delta*). Dengan mengizinkan klien untuk melakukan hidrasi dasar cache dengan permintaan awal dan pembaruan tambahan di tempat lain, Anda dapat memindahkan perhitungan dari aplikasi klien Anda ke backend. Ini jauh lebih efisien untuk aplikasi klien yang sering beralih antara status online dan offline.

Untuk mengimplementasikan Delta Sync, `Sync` kueri menggunakan `Sync` operasi pada sumber data berversi. Ketika AWS AppSync mutasi mengubah item dalam sumber data berversi, catatan perubahan itu akan disimpan di tabel *Delta* juga. Anda dapat memilih untuk menggunakan tabel *Delta* yang berbeda (misalnya satu per jenis, satu per area domain) untuk sumber data berversi lainnya atau tabel *Delta* tunggal untuk API Anda. AWS AppSync merekomendasikan untuk tidak menggunakan tabel *Delta* tunggal untuk beberapa APIs untuk menghindari tabrakan kunci utama.

Selain itu, klien Delta Sync juga dapat menerima langganan sebagai argumen, dan kemudian klien mengoordinasikan langganan menghubungkan kembali dan menulis antara transisi offline ke online. Delta Sync melakukan ini dengan melanjutkan langganan secara otomatis (termasuk backoff eksponensial dan coba lagi dengan jitter melalui skenario kesalahan jaringan yang berbeda), dan menyimpan peristiwa dalam antrian. Kueri delta atau basis yang sesuai kemudian dijalankan sebelum menggabungkan peristiwa apa pun dari antrian, dan akhirnya memproses langganan seperti biasa.

Dokumentasi untuk opsi konfigurasi klien, termasuk Amplify DataStore, tersedia di situs web [Amplify](https://aws-amplify.github.io/) Framework. Dokumentasi ini menguraikan cara mengatur sumber `Sync` dan operasi data DynamoDB berversi untuk bekerja dengan klien Delta Sync untuk akses data yang optimal.

## Pengaturan Satu-Klik
<a name="one-click-setup"></a>

Untuk secara otomatis mengatur titik akhir AWS AppSync GraphQL dengan semua resolver yang dikonfigurasi dan sumber daya yang diperlukan, gunakan templat ini AWS : 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) 

Tumpukan ini membuat sumber daya berikut di akun Anda:
+ 2 tabel DynamoDB (Basis dan Delta)
+ 1 AWS AppSync API dengan kunci API
+ 1 Peran IAM dengan kebijakan untuk tabel DynamoDB

Dua tabel digunakan untuk mempartisi kueri sinkronisasi Anda ke tabel kedua yang bertindak sebagai jurnal peristiwa yang tidak terjawab saat klien sedang offline. Untuk menjaga agar kueri tetap efisien pada tabel delta, [Amazon TTLs DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) digunakan untuk secara otomatis mengatur acara seperlunya. Waktu TTL dapat dikonfigurasi untuk kebutuhan Anda pada sumber data (Anda mungkin menginginkan ini sebagai 1 jam, 1 hari, dll.).

## Skema
<a name="schema"></a>

Untuk mendemonstrasikan Delta Sync, aplikasi sampel membuat skema *Posts* yang didukung oleh tabel *Base* dan *Delta* di DynamoDB. AWS AppSync secara otomatis menulis mutasi ke kedua tabel. Kueri sinkronisasi menarik catatan dari tabel *Base* atau *Delta* sebagaimana mestinya, dan satu langganan didefinisikan untuk menunjukkan bagaimana klien dapat memanfaatkan ini dalam logika rekoneksi mereka.

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

Skema GraphQL adalah standar, tetapi beberapa hal layak dipanggil sebelum bergerak maju. Pertama, semua mutasi secara otomatis pertama menulis ke tabel *Base* dan kemudian ke tabel *Delta*. Tabel *dasar* adalah sumber utama kebenaran untuk negara sedangkan tabel *Delta* adalah jurnal Anda. *Jika Anda tidak meneruskan`lastSync: AWSTimestamp`, `syncPosts` kueri berjalan terhadap tabel *Base* dan menghidrasi cache serta berjalan pada waktu berkala sebagai *proses penangkapan global* untuk kasus tepi saat klien offline lebih lama dari waktu TTL yang dikonfigurasi di tabel Delta.* Jika Anda meneruskan`lastSync: AWSTimestamp`, `syncPosts` kueri berjalan terhadap tabel *Delta* Anda dan digunakan oleh klien untuk mengambil peristiwa yang diubah sejak terakhir offline. Amplify klien secara otomatis meneruskan `lastSync: AWSTimestamp` nilai, dan bertahan ke disk dengan tepat.

Bidang *\$1deleted* pada *Post* digunakan untuk operasi **DELETE**. Saat klien offline dan catatan dihapus dari tabel *Dasar*, atribut ini memberi tahu klien yang melakukan sinkronisasi untuk mengusir item dari cache lokal mereka. Dalam kasus di mana klien offline untuk jangka waktu yang lebih lama dan item telah dihapus sebelum klien dapat mengambil nilai ini dengan kueri Delta Sync, peristiwa pengejaran global dalam kueri dasar (dapat dikonfigurasi di klien) berjalan dan menghapus item dari cache. Bidang ini ditandai opsional karena hanya mengembalikan nilai saat menjalankan kueri sinkronisasi yang telah menghapus item yang ada.

## Mutasi
<a name="mutations"></a>

Untuk semua mutasi, AWS AppSync lakukan Create/Update/Delete operasi standar di tabel *Base* dan juga mencatat perubahan dalam tabel *Delta* secara otomatis. Anda dapat mengurangi atau memperpanjang waktu untuk menyimpan catatan dengan memodifikasi `DeltaSyncTableTTL` nilai pada sumber data. Untuk organisasi dengan kecepatan data yang tinggi, mungkin masuk akal untuk membuat ini singkat. Atau, jika klien Anda offline untuk jangka waktu yang lebih lama, mungkin bijaksana untuk menyimpannya lebih lama.

## Pertanyaan Sinkronisasi
<a name="sync-queries"></a>

*Kueri dasar* adalah operasi DynamoDB Sync tanpa `lastSync` nilai yang ditentukan. Bagi banyak organisasi, ini berfungsi karena kueri dasar hanya berjalan pada saat startup dan secara berkala setelahnya.

*Kueri delta* adalah operasi DynamoDB Sync dengan nilai yang ditentukan. `lastSync` *Kueri delta* dijalankan setiap kali klien kembali online dari status offline (selama waktu periodik kueri dasar belum dipicu untuk dijalankan). Klien secara otomatis melacak terakhir kali mereka berhasil menjalankan kueri untuk menyinkronkan data.

Ketika kueri delta dijalankan, resolver kueri menggunakan `ds_pk` dan `ds_sk` untuk melakukan kueri hanya untuk catatan yang telah berubah sejak terakhir kali klien melakukan sinkronisasi. Klien menyimpan respons GraphQL yang sesuai.

Untuk informasi selengkapnya tentang menjalankan Kueri Sinkronisasi, lihat dokumentasi [Operasi Sinkronisasi](aws-appsync-conflict-detection-and-sync-sync-operations.md).

## Contoh
<a name="example"></a>

Mari kita mulai dulu dengan memanggil `createPost` mutasi untuk membuat item:

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

Nilai pengembalian mutasi ini akan terlihat sebagai berikut:

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

Jika Anda memeriksa isi tabel *Base*, Anda akan melihat catatan yang terlihat seperti:

```
{
  "_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"
  }
}
```

Jika Anda memeriksa isi tabel *Delta*, Anda akan melihat catatan yang terlihat seperti:

```
{
  "_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"
  }
}
```

Sekarang kita dapat mensimulasikan kueri *Base* yang akan dijalankan klien untuk menghidrasi penyimpanan data lokalnya menggunakan `syncPosts` kueri seperti:

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

Nilai kembali query *Base* ini akan terlihat sebagai berikut:

```
{
  "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
    }
  }
}
```

Kita akan menyimpan `startedAt` nilainya nanti untuk mensimulasikan kueri *Delta*, tapi pertama-tama kita perlu membuat perubahan pada tabel kita. Mari gunakan `updatePost` mutasi untuk memodifikasi Posting kami yang ada:

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

Nilai pengembalian mutasi ini akan terlihat sebagai berikut:

```
{
  "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
    }
  }
}
```

Jika Anda memeriksa isi tabel *Base* sekarang, Anda akan melihat item yang diperbarui:

```
{
  "_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"
  }
}
```

Jika Anda memeriksa isi tabel *Delta* sekarang, Anda akan melihat dua catatan:

1. Catatan saat item dibuat

1. Catatan kapan item diperbarui.

Item baru akan terlihat seperti:

```
{
  "_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"
  }
}
```

Sekarang kita dapat mensimulasikan kueri *Delta* untuk mengambil modifikasi yang terjadi ketika klien sedang offline. Kami akan menggunakan `startedAt` nilai yang dikembalikan dari kueri *Base* kami untuk membuat permintaan:

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

Nilai pengembalian kueri *Delta* ini akan terlihat sebagai berikut:

```
{
  "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
    }
  }
}
```