一个大型 GraphQL 查询与网页的多个小型查询

Question

我有兴趣获得有关我继承的 Web 应用程序架构的反馈。一些有用的背景：

• App 是客户端渲染的，用 React 编写，并使用 Apollo GraphQL 进行数据获取。 SSR 超出了范围，并且增加了比管理工具合理的复杂性。
• App 有几条主要的顶级路线。该应用程序的入口点是一个列出大量“项目”的仪表板。每个项目都有一个专用页面（我们称之为项目详细信息页面或 PDP）。一个项目由一堆项目详细信息/元数据、多个资产以及使用这些资产的帖子组成。
• 以 PDP 为例，该页面会进行大量小型 GraphQL 查询（平均页面大约 30 个）。有一个查询来获取所有项目元数据。对于每项资产，有一个查询用于获取资产详细信息，另一个查询用于解析其缩略图。对于每个帖子，还有两个查询。

我们有兴趣提高此应用程序的性能。为此，我很好奇当前的最佳实践是数据获取架构。我对此形成了意见（如下所述），并希望获得关于这是否是一个好方法的反馈。

提议的架构

• 在应用程序周围分布许多小

  useQuery

  ，可以方便地在关心该数据的地方访问相关数据。因此，目前的方法效果很好。我想避免实现大规模状态管理（如 Redux），因为我认为这会使事情变得复杂，并且很多时候会添加不必要的中间层。
• 但是，有许多小查询会增加大量网络开销，并引入大量布局变化，因为页面的不同部分在不同时间解析。
• 我的建议是为每个顶级页面创建一个更大的 GraphQL 查询。此查询将解析项目详细信息，其中包括资产 ID 和帖子 ID，然后在数据在一个有效负载中返回之前，这些详细信息也将解析为水合资产/帖子对象。这样，分布在应用程序周围的所有细粒度

  useQuery

  都可以保留在原处，并且基本上会访问 Apollo 缓存而不是网络。简而言之，使用一个大查询来水合缓存并将其用作状态管理解决方案。

这种方法有意义吗？我是不是在想什么？

Answer 1

GraphQL 的优势之一是能够准确获取您在 UI 中使用的数据，通过一次查询从后端获取该数据。保持代表性组件免受副作用也是一个很好的做法。 因此，您以更少的队列获取更多数据的想法是完全有道理的。

• 您不需要使用 apollo 客户端缓存的全局状态。
• 子组件不会发出请求，但会接收项目资产作为道具。

有一个值得注意的例外。假设您需要在项目中获取要接收并逐页显示的帖子列表。在这种情况下，在单独的查询中获取此列表可能是有意义的，以便更容易实现分页

其他需要考虑的事情：

• 您可以使用 fetchPolicy 来控制缓存行为
• 碎片可能会有帮助
• 密切关注您的查询的深度。您可能需要优化您的 graphql 后端以保持快速。