私はbackbone.usにlocalStorageアダプターを使用して、jqXHR経由ではなくローカルストレージに同期/フェッチできるようにすることを計画しています。これは、私のアプリがオフラインで動作できるようにするためです。
ただし、アプリがオンラインに戻ったら、ajax呼び出しを行ってローカルデータセットをサーバーと同期するか、または何らかの「再生」システムを組み込んで変更のみを送信します。
ただし、データセットが分岐した（サーバーとクライアントの両方で変更された）場合、どのように処理しますか？どのソースに正しいデータセットがありますか？
次の手順を実行することで、単純な双方向同期プロトコルを作成できるはずです。
同期する必要のあるすべてのテーブルに、行を変更するたびに更新される「最終更新」タイムスタンプフィールドがあります（挿入と削除を含む、さらに下を参照）。
「id」の場合、整数の自動インクリメント（次の値を把握するためにサーバーと通信する必要があります）を避け、代わりにGUIDを使用します。localStorageアダプターは、デフォルトでこれを行います。GUIDを使用すると、サーバーとクライアントの両方が相互に通信せずに新しい行を生成できます。
「ソフト削除」を使用する必要があります。実際に行を削除する代わりに、削除済みとしてマークするフラグを設定し、オブジェクトのコレクションを一覧表示する必要がある場合は常にこのフラグでフィルタリングします。そうすれば、削除も適切に伝播されます。一定期間削除されたままのすべての行に対して「ハウスキーピング」（実際には行を削除）を実行できます。この時間は、削除が確実に伝播されるように、可能な最大の「オフライン」時間よりも長くする必要があります。
クライアントのサーバーと最後に同期したときのローカルタイムスタンプを保存します。サーバーとクライアントの両方に適切なタイムゾーンでタイムスタンプを保存することが重要です。
クライアントからサーバーと同期するときは、「最終同期」タイムスタンプを送信します。サーバーは、それ以降に変更されたすべてのものを送信する必要があります。サーバーから提供された新しいタイムスタンプを使用して、それを新しい「最終同期時間」としてクライアントにローカルに保存します。更新/挿入は、GUIDに応じて取得した行を受け取りました（ローカルにある場合は更新し、ない場合は挿入します）。
ローカルに変更を保存している場合は、元のタイムスタンプ以降のすべてのローカルで変更された行をクライアントからサーバーに送信します。できればサーバーから更新を読み取る前に送信します（後で行うこともできますが、更新されたタイムスタンプを確認してください。どの更新がより新しいかを調べ、選択した競合解決ポリシーに従って処理します。重要でない場合は何も処理しません）。
実用的なクロスプラットフォームのローカルストレージの使用では、現在約2.5メガバイトのデータに制限されていることに気付いたときに苦痛を感じてください。それはうまくいけばすぐに変わるでしょう。そして、制限を回避するために代わりにIndexedDBを使用することを決定する前に、APIはまだ安定しておらず、ほとんどの実装は中途半端で互換性がありません。
データに最後に編集された日時のマーカーがあることを確認するだけではどうでしょうか。次に、比較することができます。サーバーが新しい場合は、クライアントを上書きします。その逆も同様です。