问我应该最小化我的中继应用程序中的订阅数量吗？

EN

这里有几件事需要考虑，实际上，它们都取决于你对“非常重”的定义。注“非常繁重”对于您的Elixir服务器实现来说可能意味着与在客户机上非常不同的东西，所以我将尝试涵盖一些您可能想要在这里研究的方向。

• 您的订阅传输方式是什么？Websockets在某一时刻可能很昂贵，而且在两端都很难扩展，但如果您可以处理单向数据流(仅限服务器到客户端)，SSE (服务器发送的事件)是一个很好的选择。See more on a breakdown between SSE and WS here。这更多的是对服务器的评论，而不是对客户端的评论。

• 从应用程序接口设计的角度来看，我对少数(或一个)大订阅的想法持谨慎态度。为什么？不可避免的是，您将在客户端推送从未请求过的数据；这会给客户端和服务器带来不必要的工作。此外，单个组件应该只能使用专门为其指定的数据来订阅数据尖叫。如果您采用大型订阅路线，则必须编写大量防御性代码来过滤事件流，查找所需的数据。这不应该是你的责任来进行微管理，更不用说你服务器上的脏事件流了。

这也不一定会让你走上“小订阅”的道路。最后，你可能想看看this hybrid approach，它比我自己更清楚地表达了我对这个问题的看法。TL;DR设计订阅API，以便您可以享受大量小订阅(作者将其命名为“每个实体”)的严格范围的好处，但仍然允许您共享有效负载并重用您的突变所做的相同处理程序来解析数据。

另外，如果您想使用persisted queries，混合方法将更好地为您服务。