翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
チュートリアル: バージョニングされたデータソースで Delta Sync オペレーションを使用する
注記
現在、主に APPSYNC_JS ランタイムとそのドキュメントをサポートしています。APPSYNC_JS ランタイムとそのガイドをここで使用することを検討してください。
のクライアントアプリケーションは、GraphQL レスポンスをモバイル/ウェブアプリケーションのディスクにローカルにキャッシュすることでデータ AWS AppSync を保存します。バージョン管理されたデータソースと Sync
オペレーションにより、お客様は単一のリゾルバーを使用して同期プロセスを実行することができます。これにより、クライアントは大量のレコードを含む可能性のある基本クエリでのローカルキャッシュをハイドレートし、最後のクエリ以降に変更されたデータのみを受信できます (差分更新)。クライアントが初期リクエストでキャッシュのベースハイドレートを実行し、別のリクエストでの増分更新を実行できるようにすることで、その計算をクライアントアプリケーションからバックエンドに移動できます。これは、頻繁にオンライン状態とオフラインの状態を切り替えるクライアントアプリケーションにとって効率が大きく向上します。
Delta Sync を実装するため、Sync
クエリはバージョン管理されたデータソースで Sync
オペレーションを使用します。バージョン管理されたデータソース内の項目が AWS AppSync ミューテーションによって変更されると、その変更の記録も Delta テーブルに保存されます。バージョン管理された他のデータソースに異なる Delta テーブル (タイプごとに 1 つ、ドメイン領域ごとに 1 つなど) を使用するか、 に 1 つの Delta テーブルを使用するかを選択できますAPI。プライマリキーの衝突を避けるためAPIs、複数の に 1 つの Delta テーブルを使用する AWS AppSync ことをお勧めします。
さらに、Delta Sync クライアントはサブスクリプションを引数として受け取ることもでき、オフラインからオンラインへの移行間でサブスクリプションの再接続と書き込みを調整します。そのために、Delta Sync はサブスクリプション (さまざまなネットワークエラーシナリオでの、エクスポネンシャルバックオフや、ジッターを伴う再試行など) を自動的に再開し、イベントをキューに保存します。その後、該当する差分クエリまたは基本クエリを実行してから、キュー内のイベントをマージし、最後に通常どおりにサブスクリプションを処理します。
Amplify を含むクライアント設定オプションのドキュメント DataStoreは、Amplify Framework ウェブサイト Sync
オペレーションをセットアップする方法について概説しています。
ワンクリックでのセットアップ
すべてのリゾルバーと必要な AWS リソースが設定された AWS AppSync で GraphQL エンドポイントを自動的にセットアップするには、次の AWS CloudFormation テンプレートを使用します。
このスタックはお客様のアカウントに以下のリソースを作成します。
-
2 つの DynamoDB テーブル (基本と差分)
-
API キー付き 1 AWS AppSync API
-
1 DynamoDB テーブルのポリシーを持つIAMロール
2 つのテーブルは、クライアントがオフラインのときに取得できなかったイベントのジャーナルとして機能する 2 番目のテーブルに、同期クエリを分割するために使用されます。デルタテーブルでクエリを効率的に行うために、Amazon DynamoDB TTLs は必要に応じてイベントを自動的にグルーミングするために使用されます。TTL 時間はデータソースのニーズに応じて設定できます (1 時間、1 日など)。
Schema
Delta Sync をデモンストレーションするために、サンプルアプリケーションは DynamoDB の Base テーブルと Delta テーブルによってバックアップされた Posts スキーマを作成します。 AWS AppSync はミューテーションを両方のテーブルに自動的に書き込みます。同期クエリは必要に応じて、ベーステーブルまたは差分テーブルからレコードをプルします。また、1 つのサブスクリプションは、クライアントが再接続ロジックでこのテーブルをどのように活用できるかを定義します。
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 }
GraphQL スキーマは標準的なものですが、先に進む前に注意することがいくつかあります。最初に、すべてのミューテーションは自動的にベーステーブルに書き込み、次に差分テーブルに書き込みます。基本テーブルは、実際の一元的なソースであり、一方、差分テーブルはジャーナルです。を渡さない場合lastSync: AWSTimestamp
、syncPosts
クエリは Base テーブルに対して実行され、キャッシュをハイドレートし、クライアントが Delta テーブルで設定したTTL時間よりも長くオフラインになっているエッジケースのグローバルキャッチアッププロセスとして定期的に実行されます。lastSync: AWSTimestamp
を渡す場合、syncPosts
クエリは差分テーブルに対して実行されます。クライアントはこのクエリを使用して、最後のオフライン以降に変更されたイベントを取得します。Amplify クライアントは自動的に lastSync: AWSTimestamp
値を渡し、適切にディスクに保持します。
Post の _deleted フィールドはDELETEオペレーションに使用されます。クライアントがオフラインになり、レコードが基本テーブルから削除されると、この属性は、同期中のクライアントにローカルキャッシュから項目をエビクションするように通知します。クライアントが長期間オフラインであり、クライアントが Delta Sync クエリでこの値を取得する前に項目が削除された場合は、基本クエリのグローバルキャッチアップイベント (クライアントで設定可能) が実行され、キャッシュからその項目が削除されます。このフィールドがオプションとしてマークされているのは、同期クエリの実行時に、削除された項目がある場合にのみ値を返すためです。
ミューテーション
すべてのミューテーションについて、 は Base テーブルで標準の Create/Update/Delete オペレーション AWS AppSync を実行し、Delta テーブルに変更を自動的に記録します。データソースの DeltaSyncTableTTL
値を変更することで、レコードを保持する時間を短縮または延長できます。データの速度が速い組織では、この時間を短縮するのが妥当な場合があります。あるいは、クライアントが長期間オフラインになっている場合は、この時間を延長するのが賢明でしょう。
同期クエリ
基本クエリは、lastSync
値が指定されていない DynamoDB の同期オペレーションです。多くの組織にとって、基本クエリで十分です。基本クエリは起動時に実行され、以降は定期的に実行されるためです。
差分クエリは、lastSync
値が指定された DynamoDB の同期オペレーションです。差分クエリは、クライアントがオフライン状態からオンライン状態に戻るたびに実行されます (基本クエリが定期的にトリガーされていない場合)。クライアントは、データを同期するクエリを最後に正常に実行した時刻を自動的に追跡します。
差分クエリが実行されると、クエリのリゾルバーは ds_pk
と ds_sk
を使用して、クライアントが前回同期を実行してから変更されたレコードに対してのみクエリを実行します。クライアントは該当する GraphQL レスポンスを保存します。
同期クエリの実行の詳細については、同期オペレーションのドキュメントを参照してください。
例
まず、項目を作成するために createPost
ミューテーションを呼び出すことから始めましょう。
mutation create { createPost(input: {author: "Nadia", title: "My First Post", content: "Hello World"}) { id author title content _version _lastChangedAt _deleted } }
このミューテーションの戻り値は次のようになります。
{ "data": { "createPost": { "id": "81d36bbb-1579-4efe-92b8-2e3f679f628b", "author": "Nadia", "title": "My First Post", "content": "Hello World", "_version": 1, "_lastChangedAt": 1574469356331, "_deleted": null } } }
ベーステーブルの内容を調べると、次のようなレコードがあります。
{ "_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" } }
差分テーブルの内容を調べると、次のようなレコードがあります。
{ "_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" } }
これで、クライアントが syncPosts
クエリなどを実行してローカルデータストアをハイドレートするために実行する基本クエリをシミュレーションすることができます。
query baseQuery { syncPosts(limit: 100, lastSync: null, nextToken: null) { items { id author title content _version _lastChangedAt } startedAt nextToken } }
この基本クエリの戻り値は次のようになります。
{ "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 } } }
差分クエリをシミュレーションするために後で startedAt
値を保存しますが、まずはテーブルを変更する必要があります。updatePost
ミューテーションを使って既存の投稿を変更しましょう。
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 } }
このミューテーションの戻り値は次のようになります。
{ "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 } } }
ここでベーステーブルの内容を調べると、更新された項目が表示されます。
{ "_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" } }
ここで差分テーブルの内容を調べると、次の 2 つのレコードがあります。
-
項目が作成されたときのレコード
-
項目が更新されたときのレコード
新しい項目は次のようになります。
{ "_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" } }
差分クエリをシミュレートして、クライアントがオフラインのときに発生した変更を取得できるようになりました。リクエストを行うために、基本クエリから返された値 startedAt
を使用します。
query delta { syncPosts(limit: 100, lastSync: 1574469602238, nextToken: null) { items { id author title content _version } startedAt nextToken } }
この差分クエリの戻り値は次のようになります。
{ "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 } } }