閉まっている。この質問には詳細または明確さが必要です。現在回答を受け付けておりません。
この質問を改善したいですか?この投稿を編集して詳細を追加し、問題を明確にします。
3 年前
に閉鎖されました。この質問を改善してください
前提
当面の問題は多面的です。実際の運用環境でどのような方針が取られているのか、安全性と運用コストなどの観点からより良いソリューションと考えられるものは何か。
私は現在、アプリの状態ツリーを保存するために Redux を利用した React Web アプリを開発しています。同時に、React アプリがさまざまな操作に依存できるバックエンド サーバーとして機能する RESTful API を Spring Boot で作成しています。ユーザーデータ（認証、メタデータ、アプリケーション固有のデータ）を（セキュリティ上の理由から）Spring バックエンドのみがアクセスできる Firestore に保存しています。ユーザーが React アプリに正しくログインすると、GET 要求が送信されます。uest は Firestore からデータを取得するためにディスパッチされます。
ジレンマ
ユーザーがログイン中にデータを変更すると、次のようなジレンマに直面します。
特に Redux でローカル状態を更新してから、POST リクエストをディスパッチして、
Firestoreに保存されているデータ、
または、最初から POST リクエストを直接ディスパッチし、別の GET リクエストをディスパッチして更新された状態を取得します。
長所と短所
最初のアプローチは、ユーザーが自分のアクションが完了したという視覚的なフィードバックを即座に得ることができるため、ユーザー エクスペリエンスの点で優れていると思われます (投稿のリストから投稿を削除したいとすると、その投稿はすぐに削除されます)。ローカル ストレージはアプリのレンダリングを担当するため、POST リクエストが完了するのを待っても、er は正しく最新の状態になります。もちろん、これがすべて良いというわけではありません。データベース内の実際のデータがまだ更新されていないときにローカル ストレージを変更することは、まったく安全ではなく、実際には同期的ではないからです。
2 番目のアプローチでは、完了までに長い時間がかかる (またはかからない) 可能性のある、骨の折れる操作が必要になります。ただし、少なくとも Firestore データベースの表現が破損していない限り、状態は常に正しいままです。
以上のことを踏まえて、ユーザー エクスペリエンスと安全性の両方を満足させる正しいアプローチについてどう思いますか。 (ローカル ストレージがデータベースとの同期の基礎として検索されることは決してないことに注意してください。ローカル ストレージが改ざんまたは破損した場合、変更はデータベースに到達しません。)
------------------------
クライアント側の Firestore SDK を使用している場合、2 つのアプローチは実際には同じ方法で実装されます。
API を呼び出してドキュメントを更新すると、サーバーに更新を送信する前でも、所有しているローカル リスナーに対してイベントが即座に起動されます。サーバーから応答を取得すると (デバイスがオフラインの場合はかなり遅くなる可能性があります)、クライアントはステータスを反映するためにローカル キャッシュのメタデータを更新するか、(書き込みが失敗したか拒否された場合は) ローカル キャッシュのメタデータを元に戻します。データを正しい状態に戻します。
UI では、ローカル イベントに対して発生したデータを表示することもできます (これは、ost アプリはそうします)、またはメタデータを反映することもできます。後者は、DocumentSnapshot.metadata 内の 2 つのフラグの形式をとります。そこから:
hasPendingWrites: バックエンドにまだコミットされていないローカル書き込み (set() または update() 呼び出しなど) の結果がスナップショットに含まれている場合は true
fromCache: スナップショットが、保証された最新のサーバー データではなく、キャッシュされたデータから作成された場合は True。
詳細については、ドキュメントのリンクを確認してください。
1
あなたの回答とリンクしたドキュメントを通じて、私は確か、私が検索していた用語は「遅延補償」でした。最初にローカル スケールで変更を反映し、サーバー側でエラーが発生した場合はそれらの変更を元に戻すという、ご提案いただいた方法を実装します。
– 無効なパス
2020 年 9 月 4 日 10:49
