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