在观看了相当多的 youtube 视频之后，似乎 Google 在更改存储在多个地方的数据时提倡多路径更新，但是，我越是弄乱云功能，似乎它们甚至更多可行的选择，因为他们可以坐在后面聆听对特定参考的更改，并根据需要将更改实时推送到其他参考。走这条路有缺点吗？只是好奇为什么谷歌不推荐它们用于这个用例。
【问题讨论】：
标签： firebase firebase-realtime-database google-cloud-functions
更新：在我写这篇文章的时候，我收到了谷歌关于我的问题的回复。现在改变我们的应用方向为时已晚，但它可能对其他人有用。
如果您的函数没有返回值，则服务器不知道要等待多长时间才能放弃并终止它。我敢打赌，这可能是数据库调用没有被调用的原因。
请注意，由于
DatabaseReference.set()返回一个承诺，您可以根据需要简单地返回它。此外，您可能需要添加
.catch()并记录输出以验证set()操作没有失败。~firebase-support@google.com
更新：我在上个月左右使用云功能的经历有点让人又爱又恨。我们的许多非规范化数据都依赖于 Cloud Functions 来保持一切同步。不幸的是（从一开始这就是一个坏主意）我们正在处理交易/货币数据并将其存储在多个区域中很不舒服。当我们开始遇到 Cloud Functions 问题时，即它们在 DB 侦听器上的执行不是 100% 可靠时，我们知道 Firebase 至少对我们的事务数据不起作用。
总体而言，这个概念很棒。它们在触发时工作得非常好，但由于触发功能的一些不一致，它们对于我们的用例来说不够可靠。
我们目前使用 SQL 处理我们的事务数据，然后将用户数据和其他需要实时维护的对象存储在 Firebase 中。到目前为止，这对我们来说效果很好。
【讨论】：