问题描述
前提
当前的问题是多方面的。在实际生产环境中要遵循的过程是什么，就安全性与生产成本而言，什么被认为是更好的解决方案，等等。
我目前正在开发一个利用Redux来存储应用程序状态树的React Web应用程序。同时，我正在使用Spring Boot创建一个RESTful API，以用作React应用程序可以依赖其进行各种操作的后端服务器。我将用户数据（包括身份验证，元数据和特定于应用程序的数据）存储在只能由Spring后端访问的Firestore中（出于安全原因）。当用户正确登录React App时，将调度GET请求以从Firestore提取其数据。
困境
利弊
-
在用户体验方面，第一种方法似乎更好，因为用户将立即收到视觉反馈，表明他的动作已完成（例如，他想从帖子列表中删除帖子，该帖子会立即删除）。本地存储负责应用的呈现，因此无论等待POST请求完成，用户都将保持最新状态。当然，这还不尽如人意，因为当数据库中的实际数据尚未更新时，修改本地存储根本不安全或无法真正同步。
-
第二种方法，它引入了可能很费力的操作，可能需要很长时间才能得出结论。但是状态始终是正确的，或者至少只要Firestore数据库具有正确的表示形式即可。
因此，话虽如此，您对同时满足用户体验和安全性的正确方法有何看法。 （请记住，切勿将本地存储作为与数据库同步的基础。如果本地存储被篡改或损坏，更改将永远不会到达数据库。）
解决方法
使用客户端Firestore SDK时，这两种方法实际上是以相同的方式实现的。
您需要调用API来更新文档，然后甚至会在将更新发送到服务器之前立即为您拥有的任何本地listeners触发事件。当它从服务器获得响应时（如果设备处于脱机状态，则可能稍后会出现 ），客户端将更新本地缓存的元数据以反映状态，或者（如果写入失败/被拒绝）将本地数据恢复为正确状态。
在用户界面中，您可以只显示触发本地事件的数据（大多数应用程序都这样做），也可以反映元数据。后者在DocumentSnapshot.metadata中采用两个标志的形式。从那里：
hasPendingWrites：True（如果快照包含尚未提交到后端的本地写入（例如set()或update()调用）的结果
fromCache：True，如果快照是从缓存的数据而不是由保证的最新服务器数据创建的。
查看文档链接以获取全部详细信息。