我具有以下数据库结构：
Posts/uid/postID/mediaData...
Timeline/UID/uid:RandID/postRefrence
我打算使用这样的数据库结构，因为为了节省时间，我想使用一种易于编码的数据库结构，该结构仍然可以扩展到大量用户（最多100个）并快速进行更改一种更可扩展的方法：仅更新用户postsNode，然后使用firebaseFunctions在后台运行代码，该代码将复制数据并将其添加到所有关注者。
但是，我在执行此操作时遇到了问题。如果用户发布了帖子，那么有人跟随了该用户怎么办，目前我没有代码来处理这种情况，因此新关注者不会从他关注的用户那里获得任何帖子（添加到我从中获取的时间轴） 。
所以看来，我唯一的选择是必须使用消防功能。这样每个人都可以观察数据库中的另一个节点：whoFollowesME。从那里，我将不得不（在后端）监视更新，当有更新时，我将不得不（例如有人跟随用户）循环浏览最后的x或所有帖子，并将其引用添加到用户时间轴。 / p>
问题：
这是一个好方法吗？？我从未使用过消防功能，所以不确定它有多简单。
我还要考虑其他吗？
答案 0 :(得分：1)
如果Cloud Functions可以这样做，那么客户端代码也可以。至少从SDK的角度来看，Cloud Functions对数据库没有什么作用，而客户端也没有。该选择通常更多地基于安全性考虑。
至于您对从客户端编写许多文档发表评论： “更好地使用”不同于“可以做到”。您可以执行fan-out from the client-side SDKs，也可以使用我们的管理SDK。后者的主要优点是您可以在您选择的环境中运行它们，例如开发机器，您控制的服务器或Cloud Functions，因此您可以更好地控制带宽/ CPU /内存/等。但这与他们从SDK级别可以做什么无关。如果您对Swift更加熟悉，我会从这里开始，只是为了让您更轻松。
如果您已经了解JavaScript，请首先尝试在更快的环境中进行扇出，例如本地HTML / JS文件，StackBlitz / jsbin或刚刚与节点扇出一起运行的本地Node.js脚本。 js。一旦在那里工作，您只需要关注Cloud Functions位即可。这就是我经常编写我的Cloud Functions的方式，并且大大加快了它们的开发流程。