Node.js对接Firestore实现实时更新：服务端操作后前端无刷新同步咨询

可以实现Firestore变更时自动更新应用数据，针对你的场景有两类落地方式，同时也会解答是否要迁移数据库调用的问题。

方案1：最低成本改造（无需调整现有架构） #

• 轻量实现：删除成功后直接操作DOM
  你现在的客户端删除请求没有加成功回调，只需要在fetch后补充成功逻辑，直接移除页面对应的奖励条目即可，改造成本极低：

  fetch("/deleteReward/" + this.value, {
      method: "DELETE",
      headers: {
        Accept: "application/json",
        "Content-Type": "application/json",
        "CSRF-Token": Cookies.get("XSRF-TOKEN"),
      },
  }).then(res => {
      if(res.ok) {
          // 这里获取当前按钮对应的奖励条目DOM，直接移除，类名根据实际页面调整即可
          this.closest('.reward-item').remove()
      }
  })
  

  这个方法适合只有当前用户会修改自己奖励库的场景，不需要处理多端同时修改的同步问题。
• 全场景实时同步实现：客户端加Firestore实时监听器
  即使写操作全部走服务端，客户端依然可以直接接入Firebase客户端SDK，监听对应商户文档的rewards字段变动，每次变更触发时重新渲染页面的奖励列表即可，无需刷新页面。
  只需要注意配置Firestore安全规则，限制商户只能读取自己账号下的奖励数据，避免越权访问即可。

方案2：数据库调用是否要迁移到前端的分析 #

可以根据你的业务需求选择，两种方式的优劣势如下：

• 迁移到前端的优势：
  • 可以直接复用Firestore原生的实时更新、权限校验能力，不需要自己编写大量后端接口
  • 后续新增、修改权益的逻辑都可以直接在前端实现，迭代效率更高
• 迁移到前端的注意事项：
  • 必须编写完善的Firestore安全规则，所有的权限校验、参数合法性校验都要在规则侧落地，防止恶意用户篡改数据
  • 敏感业务逻辑如果不希望暴露在前端，不建议迁移
• 不迁移的替代实时方案：
  如果要保留服务端操作数据库的架构，又要支持多端同步，也可以在服务端接入Firestore实时监听，通过WebSocket把变更推送给对应的客户端，但这种方案的开发和运维成本远高于前两种，非必要不选择。

现有代码问题修复建议 #

1. 服务端删除接口没有返回响应，你当前的app.delete逻辑里无论成功失败都没有给客户端返回res.json()或者res.send()，会导致客户端fetch请求超时，需要补充：

admin
.auth()
.verifySessionCookie(idToken, true /** checkRevoked */)
.then((decodedClaims) => {
  return deleteReward(decodedClaims.user_id, rewardId)
})
.then(() => res.json({success: true}))
.catch((error) => {
  console.log(error)
  res.status(500).json({success: false, error: error.message})
});

2. deleteReward函数中硬编码了文档ID KOBmyfQEu4urNGgBTuiJ，没有使用传入的restaurantId参数，会导致所有商户的删除操作都修改同一个门店的奖励库，需要替换为传入的restaurantId；同时arrayRemove里的对象是硬编码的，没有根据传入的rewardId匹配对应要删除的权益对象，会导致删除逻辑不符合预期。

内容的提问来源于stack exchange，提问作者Shaheryar Ajmal