简体繁体 English

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

[英]Should I minimise the number of subscriptions in my relay application?

原文 2020-12-27 22:27:49 4 1 graphql/ relay/ relaymodern/ react-relay/ graphql-relay

I am new to using graphql and we have built a backend graphql server using elixir and we are building a frontend app using react and react-relay.我是使用 graphql 的新手，我们已经使用 elixir 构建了一个使用 react 和 react-relay 的前端应用程序。

My question is whether it is better to have one large subscription at the root of my query renderer instead of having loads of smaller subscriptions for individual components.我的问题是，在我的查询渲染器的根目录下拥有一个大型订阅是否更好，而不是为单个组件拥有大量较小的订阅。 I think I would prefer using lots and lots of smaller subscriptions rather than fewer (or even one) very large subscriptions but there are concerns that too many subscriptions will be very heavy.我认为我更喜欢使用大量较小的订阅，而不是更少（甚至一个）非常大的订阅，但有人担心订阅过多会非常沉重。 Is this valid?这是有效的吗？

TIA TIA

1 个解决方案

There are a few things to consider here, and really, they all depend on what your definition of "very heavy" is.这里有几件事要考虑，实际上，它们都取决于您对“非常重”的定义是什么。 Note "very heavy" might mean something very different for your Elixir server implementation than it does on the client, so I will attempt to cover some directions you may want to investigate for both here.请注意，“非常重”可能意味着您的 Elixir 服务器实现与在客户端上的实现非常不同，因此我将尝试介绍您可能想要在此处调查的一些方向。

What is your subscription transport?您的订阅传输是什么？ Websockets can be expensive and difficult to scale on both ends at a certain point, but if you can deal with unidirectional data flow (server to client only), SSE (Server-Sent Events) are a great option. Websocket 可能很昂贵，并且在某个时候很难在两端扩展，但是如果您可以处理单向数据流（仅限服务器到客户端），那么 SSE（服务器发送事件）是一个不错的选择。 See more on a breakdown between SSE and WS here .在此处查看有关 SSE 和 WS 之间细分的更多信息。 This is more a comment on your server than on your client.这更像是对您的服务器的评论，而不是对您的客户端的评论。
From an API design perspective, I'd caution against the few (or one) large subscriptions idea.从 API 设计的角度来看，我会警告不要使用少数（或一个）大型订阅的想法。 Why?为什么？ Inevitably, you are going to be pushing data on the client that it never asked for;不可避免地，您将在客户端上推送它从未要求过的数据； this causes unnecessary work for both client and server.这会给客户端和服务器带来不必要的工作。 Furthermore, an individual component should only be able to subscribe to data screams with data specifically designated for it.此外，单个组件应该只能使用专门为其指定的数据订阅数据尖叫。 If you go the large subscription route, then you'll have to write a good deal of defensive code to filter the event stream, looking for the data you need.如果你是 go 的大订阅路线，那么你将不得不编写大量的防御性代码来过滤事件 stream，寻找你需要的数据。 That shouldn't be your responsibility to micromanage, not to mention the dirty event stream on your server.这不应该是你对微观管理的责任，更不用说你服务器上的脏事件 stream 了。

This is not necessarily to lead you down the "small subscription" route either.这也不一定会引导您走“小额订阅”路线。 Ultimately, you might want to look at this hybrid approach , which articulates my opinions on the matter better than I can myself.最终，您可能想看看这种混合方法，它比我自己更好地表达了我对此事的看法。 TL;DR design the subscriptions API so that you can enjoy the tightly scoped benefits of lots of small subscriptions ("per entity," as the author titles them), but still allow you to share payloads and reuse the same handlers that your mutations do to resolve data. TL;DR 设计订阅 API 以便您可以享受许多小型订阅（“每个实体”，正如作者对它们的标题）的严格范围的好处，但仍然允许您共享有效负载并重用您的突变所做的相同处理程序来解析数据。

Plus, if you wanted to use persisted queries the hybrid approach is going to serve you better.另外，如果您想使用持久查询，混合方法将为您提供更好的服务。