客户端扇出真的是个好主意吗？答案

【问题标题】：Is client fanout really a good idea?客户端扇出真的是个好主意吗？
【发布时间】：2017-02-06 19:30:54
【问题描述】：

我目前正在构建一个基于 firebase 的社区，该社区的时间线和帖子类似于 Facebook。当用户创建帖子时，它应该会自动弹出在他或她的关注者的时间线中。

Google 建议通过扇出更新来执行此操作：https://firebase.googleblog.com/2015/10/client-side-fan-out-for-data-consistency_73.html

但我想知道：如果一个用户有 - 比如说 - 20k 粉丝，我首先必须下载他所有粉丝的列表（即使有像 { <user-id>: true } 这样的索引，这也是相当不错的）大），然后使用扇出方法更新每个用户的时间线，如下所示：

// followers = { <user-id-1>: true, <user-id-2>: true, ... }
const fanout = {};
const post = { text: 'foo', timestamp: firebase.database.ServerValue.TIMESTAMP };
Object.keys(followers).map((key) => {
    fanout[`timeline/${key}/${postId}`] = post;
});
firebase.database().ref().update(fanout);

这对于安全规则来说也很难确定允许用户更新哪个时间线。

我的方法是监视全局帖子参考的服务器。如果有更新或添加的孩子，它会查找帖子创建者的关注者并相应地更新时间线。这样我就不必摆弄安全规则，客户端要做的工作也少了很多。

我错了吗？

【问题讨论】：

标签： javascript reactjs firebase firebase-realtime-database

【解决方案1】：

如果您愿意在服务器上运行扇出，请务必这样做。当要扇出的数据量太大而无法在客户端上运行时，它确实会消除潜在的瓶颈。

但是绝大多数项目永远不会达到这个水平，而且在项目生命周期的早期，许多开发人员都不愿意运行服务器，即使只是为了分散数据。所以客户端扇出对于这些开发人员来说是一个很好的选择。

【讨论】：

谢谢！在 Firebase 中，一切似乎都有些不同，这就是我想知道的原因。