Firebase - 多路径更新或云函数监听器

Question

看了相当多的 youtube 视频后，Google 似乎提倡在更改存储在多个地方的数据时进行多路径更新，但是，我对云功能的了解越多，似乎他们甚至是更可行的选择，因为他们可以坐在后面听取对特定参考的更改，并根据需要实时将更改推送到其他参考。走这条路有缺点吗？只是好奇为什么 Google 不推荐他们用于这个用例。

Answer 1

最新更新： 就在我写这篇文章的时候，我收到了 Google 关于我的问题的回复。现在改变我们的应用程序方向为时已晚，但它可能对其他人有用。

If your function doesn't return a value, then the server doesn't know how long to wait before giving up and terminating it. I'd wager a quick guess that this might be why the DB calls aren't getting invoked.

Note that since DatabaseReference.set() returns a promise, you can simply return that if you want.

Also, you may want to add a .catch() and log the output to verify the set() op isn't failing.

~firebase-support@google.com

更新： 在过去一个月左右的时间里，我对云功能的体验有点让人又爱又恨。我们的许多非规范化数据都依赖 Cloud Functions 来保持一切同步。不幸的是（这从一开始就是一个坏主意）我们正在处理 transactional/money 数据并且将其存储在多个区域是不舒服的。当我们开始遇到 Cloud Functions 问题时，即它们在数据库侦听器上的执行不是 100% 可靠时，我们知道 Firebase 至少无法处理我们的交易数据。

总的来说，这个概念很棒。它们在触发时工作得非常好，但由于触发函数时存在一些不一致，它们对于我们的用例来说不够可靠。

我们目前使用 SQL 来处理我们的交易数据，然后将用户数据和其他需要在 Firebase 中实时维护的对象存储起来。到目前为止，这对我们来说效果很好。