Tutorial: Menggunakan operasi Delta Sync pada sumber data berversi - AWS AppSync

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

Tutorial: Menggunakan operasi Delta Sync pada sumber data berversi

catatan

Kami sekarang terutama mendukung runtime APPSYNC _JS dan dokumentasinya. Harap pertimbangkan untuk menggunakan runtime APPSYNC _JS dan panduannya di sini.

Aplikasi klien dalam AWS AppSync menyimpan data dengan menyimpan respons GraphQL secara lokal ke disk dalam aplikasi seluler/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 Anda. API 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 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

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

Blue button labeled "Launch Stack" with an arrow icon indicating an action to start.

Tumpukan ini membuat sumber daya berikut di akun Anda:

  • 2 tabel DynamoDB (Basis dan Delta)

  • 1 AWS AppSync API dengan API kunci

  • 1 IAM Peran 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 digunakan untuk secara otomatis mengatur acara seperlunya. TTLWaktu dapat dikonfigurasi untuk kebutuhan Anda pada sumber data (Anda mungkin menginginkan ini sebagai 1 jam, 1 hari, dll.).

Skema

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 meneruskanlastSync: 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 TTL waktu yang dikonfigurasi di tabel Delta. Jika Anda meneruskanlastSync: 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 _deleted pada Post digunakan untuk DELETEoperasi. 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

Untuk semua mutasi, AWS AppSync lakukan operasi Buat/Perbarui/Hapus standar di tabel Dasar 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

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.

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

Contoh

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

  2. 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 } } }