我应该尽量减少中继应用程序中的订阅数量吗？

Posted 2023-03-08

【中文标题】我应该尽量减少中继应用程序中的订阅数量吗？

【英文标题】：Should I minimise the number of subscriptions in my relay application?

【发布时间】：2021-04-04 20:07:24

【问题描述】：

我是使用 graphql 的新手，我们已经使用 elixir 构建了一个后端 graphql 服务器，并且我们正在使用 react 和 react-relay 构建一个前端应用程序。

我的问题是，在我的查询渲染器的根目录下拥有一个大型订阅是否比为单个组件拥有大量较小的订阅更好。我认为我更喜欢使用大量较小的订阅，而不是更少（甚至一个）非常大的订阅，但有人担心订阅过多会非常沉重。这有效吗？

TIA

【参考方案1】：

这里有几件事需要考虑，实际上，它们都取决于您对“非常重”的定义是什么。请注意，“非常繁重”可能意味着您的 Elixir 服务器实现与客户端实现非常不同，因此我将尝试在此处介绍您可能想要调查的一些方向。

您的订阅传输是什么？ Websockets 可能很昂贵，并且在某些时候很难在两端进行扩展，但是如果您可以处理单向数据流（仅限服务器到客户端），那么 SSE（服务器发送事件）是一个不错的选择。 See more on a breakdown between SSE and WS here。这更像是对您的服务器的评论，而不是对您的客户端的评论。

从 API 设计的角度来看，我会告诫不要使用少数（或一个）大型订阅的想法。为什么？不可避免地，您将在客户端上推送它从未要求过的数据；这会给客户端和服务器带来不必要的工作。此外，单个组件应该只能使用专门为其指定的数据订阅数据尖叫。如果您采用大型订阅路线，那么您将不得不编写大量防御性代码来过滤事件流，寻找您需要的数据。这不应该是你的责任，更不用说你服务器上的脏事件流了。

这也不一定会引导您走“小额订阅”路线。最后，你可能想看看this hybrid approach，它比我自己更好地表达了我对此事的看法。 TL;DR 设计订阅 API 以便您可以享受许多小型订阅（“每个实体”，正如作者对其命名）的严格范围的好处，但仍然允许您共享有效负载并重用您的突变所做的相同处理程序解析数据。

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