我知道没有正确的答案，但我想听听你对一个具体例子的看法： 假设您有餐厅，这家餐厅有一个具有 3 个应用程序的订购系统：
-
对于餐厅的"老板"(因为缺乏更好的词)。
-
对于送货员。
-
为客户(订购食物)。
-
工作方式更像是管理员帐户。因此，我决定将云功能与管理员 sdk 一起使用，以添加新用户，即送货员帐户。菜单和菜肴的构建都在这里进行。我目前只使用客户端 sdk，仅仅是因为它对于如此简单的任务来说速度很快，缓存是一大优势。现在，在安全方面，我的想法是"老板"不想篡改自己的文档，因此允许他通过安全规则读写访问此处的所有文档似乎很好。不过，想听听你的想法。
-
现在，这个有点困难，因为我在这里只使用客户端 sdk，并允许对送货员的订单文档进行读写访问。这可能有点幼稚，因为允许对送货员进行写入访问为篡改订单文档上的特定字段提供了可能性。我决定这样做只是为了速度和缓存，但现在我想我应该改变它。"老板"和送货员之间还有一个聊天功能。我为每个对话使用一个文档，如果它超过 1mb，我有一个云功能，如果接近此限制，它会存档较旧的消息。但是由于对聊天文档的所有读取和写入都可以通过客户端 sdk 从交付人员那里发生，这使得它在安全方面也有点开放(即使有更复杂的安全规则)。如果我停止使用一个文档并且每条消息都有一个文档，我也许能够解决这个问题。通过一些良好的安全规则，我可以使其更安全，但不能与使用云功能相比。
在这里，我 根本没有在前端编写任何代码，我正在考虑在提交订单请求时使用云函数以确保安全性。
我真的很喜欢仅使用客户端时的速度(用于简单查询)和缓存。如果我有一些计算量更大或更复杂的东西，我使用了云函数，这工作正常。我也喜欢在客户端 sdk 完成某些操作后使用云函数来触发内容。我最担心的是使用云函数作为简单查询的包装器或中间人，是冷启动的速度(有时与仅使用客户端 sdk 相比，它在启动后有点慢)。我不太喜欢丢失客户端 sdk 的缓存和流。但是，由于安全性非常重要，我对该怎么做有点扭曲。 我不是在要求任何代码或完美的答案，只是你的想法，如果你对此有任何经验。我倾向于坚持使用客户端 sdk，即使是送货员，并尝试通过更好和复杂的安全规则来调节这一点。然后，也许尝试自己利用它，看看它有多好。你有什么想法？
我读了这篇文章，我觉得很有用：https://medium.com/firebase-developers/should-i-query-my-firebase-database-directly-or-us 并观看了Firebase关于云函数的视频系列，我发现这些文档非常有用(云函数和firestore)。
每当需要处理客户端可能泄露或操纵超出Security Rules可以防止的范围的敏感信息时，都应使用Cloud Functions作为权限来源。
- 恢复 + 安全规则
- 恢复 + 安全规则
- 恢复 + 安全规则
- 云函数仅适用于 admin-sdk，您无法在节点.js环境中成功使用客户端模块。
- 安全规则是你的朋友，你可以专门拒绝写入和更新 - 聊天应该通过实时数据库进行管理
- 使用云功能完成订单，交叉参考价格等，但其余的可以使用Firestore和智能安全规则来完成，以防止非法编辑。
- 此外，还可以使用自定义声明来指示谁具有什么角色，并验证谁可以使用规则执行哪些操作。 所以只有老板才能发放退款、波次费用等。
参考：
- https://firebase.google.com/docs/firestore/security/rules-conditions#data_validation
- https://firebase.google.com/docs/auth/admin/custom-claims