【问题标题】:Architecture for avoiding repeated data in GraphQLGraphQL 中避免重复数据的架构
【发布时间】:2021-11-14 00:14:39
【问题描述】:

我有一个应用程序,其中相同的数据出现在图中的许多地方,需要优化数据查询以避免过于频繁地处理和发送相同的数据。

例如,考虑以下伪模式:

type Group {
  name: String
  members: [Person]
}
type Person {
  name: String
  email: String
  avatar: Avatar
  follows: [Person]
  followedBy: [Person]
  contacts: [Person]
  groups: [Group]
  bookmarks: [Bookmark]
  sentMessages: [Message]
  receivedMessages: [Message]
}
type Message {
  text: String
  author: Person
  recipients: [Person]
}
type Bookmark {
  message: Message
}

查询用户数据很容易包含数百个(如果不是数千个)个人对象,即使它的朋友/联系人/关注的小圈子仅包含数十个不同的用户。

在我的实际实现中,大约 80% 的 GraphQL 查询(以字节为单位)是冗余的,考虑到客户端在同一空间中执行许多不同的查询,超过 90% 的所有传输和处理的数据都是冗余的。

我怎样才能改进模型,这样我就不必一次又一次地加载相同的数据,而不会使客户端过于复杂?

我将 Apollo 用于 GraphQL 客户端和服务器。

【问题讨论】:

    标签: graphql apollo


    【解决方案1】:

    对关系使用/实现分页(而不仅仅是数组)——这样你可以查询count/total(在没有数组处理的情况下渲染它)和id数组——通常不需要查询/完全加入人员表 (DB)。

    仅使用传递的id 属性呈现Person 组件列表(反应?)...仅呈现Person 获取更多详细信息(如果未缓存,则使用批处理合并请求)在内部消费/呈现。

    【讨论】:

    • 感谢您的回复。我们实际上在有意义的地方使用了分页,我只是认为这对于这个特定问题并不重要。我一直在考虑只发送 id/ref 并将嵌套的 Person 分隔成一个单独的查找查询,它看起来不是很 GraphQL。
    • 如果您知道有关该主题的任何内容,我将不胜感激。
    • graphQL 有助于过度获取,apollo 有助于重用已经 [过度] 获取的数据......分页限制有助于滥用 [过度获取](获取事实上未使用的数据,获取 1xx,显示 1x)。 .. 允许显示非常有用的数据,例如“后跟 x、y、z(头像+信息)和 1xx 其他(计数器)”
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-04-02
    • 2021-12-28
    • 2013-01-31
    • 1970-01-01
    • 2017-06-17
    • 2020-10-24
    • 1970-01-01
    相关资源
    最近更新 更多