保留几个简单（普通）订阅和保留一个复杂（多级）订阅之间有什么实际区别吗？ （例如使用发布复合）
在我看来应该没有任何区别，但我想确定一下。我更喜欢坚持使用普通的 subs，因为它似乎使高度模块化项目中的代码更清晰，但前提是这不会带来任何性能或可伸缩性问题。
那么，有人可以帮帮我吗？
【问题讨论】：
标签： javascript meteor
进行多个普通订阅与保持复杂的复合订阅有两个主要区别
1) 曝光/隐私
复合订阅允许您在服务器端执行连接/过滤，以确保您只发送当前用户有权查看的数据。您不想将整个数据库暴露给客户端。请记住，即使您的 UI 没有显示数据，用户也可以进入控制台并获取您的服务器发布的所有数据。
2) 客户表现
如果您拥有大型数据集，则在客户端上执行连接/过滤可能会很昂贵。这当然取决于您的应用程序。此外，如果数据库不断更新，并且这些更新不应该对用户可见；您将不断需要将更新传输到客户端，而不会从网络费用中获益。
【讨论】：
如果没有针对您的应用程序的更多详细信息，我认为无法给出准确的答案。话虽如此，我认为这是一个重要的问题，所以我将概述一些需要考虑的事项。
需要明确的是，这个答案的重点将是辩论服务器端和客户端reactive joins 的相对优点。
决定是否需要反应性
您可以在发布者中生成多个集合的简单连接，而无需任何反应（请参阅上面文章中的第一个示例）。根据问题的性质，您可能并不真正需要反应式联接。想象一下，您要加入 cmets 和作者，但您的应用程序总是已经发布了所有可能的作者。在这种情况下，非响应式连接的根本缺陷（新父级后缺少子文档）将不存在，因此响应式发布是多余的。
考虑您的安全模型
正如我在 template joins 上的文章中提到的，服务器端联接具有将所有数据捆绑在一起的优势，而客户端联接需要更细粒度的发布者。考虑拥有像commentsAndAuthors 这样的发布者与comments 和users 的两个通用实现的安全隐患。后者表明任何人都可以在没有上下文的情况下请求一组用户文档。
服务器连接可能会占用 CPU 和内存
仔细查看您正在考虑用于服务器端连接的库的实现。其中一些使用observe，这要求依赖链中的每个完整文档都保存在内存中。其他的仅在observeChanges 上实现，这更有效，但使包在它们可以做的事情上不太灵活。
寻找观察者重用
您的目标之一应该是reuse your observers。换句话说，假设您将有 S 个并发订阅，您最终只会做 ~(S-I) 工作，其中 I 是客户端中相同观察者的数量。根据订阅的性质，您可能会看到更细化的订阅带来更多的观察者重用，但这是特定于应用程序的。
注意延迟
服务器端连接的一大优势是它们可以一次有效地传递所有文档。将其与在激活子订阅之前必须等待每组父文档到达的客户端连接进行比较。在将初始文档集交付给客户端之前，N 级客户端连接将进行 N 次往返。
结论
在决定对每份出版物使用哪种技术时，您需要考虑以上所有因素。现实情况是，在 kadira 之类的东西上对实时应用进行基准测试是得出结论性答案的唯一方法。
【讨论】：