Node.js GraphQL：一个大查询与许多小查询

我知道这个问题和时间一样古老，他们的问题也不是万能的。但我认为可能会有一个坚实的模式，我不想发明轮子

考虑以下两个模式选项：

方法1）我最初的实现 方法2）我目前的实验方法 区别在于：

在方法1）中，notes查询将返回可能较大的notes对象的列表

在方法2）中，notes查询将返回一个轻得多的负载，但随后将需要执行n个额外的查询

因此，我的问题是使用带内存缓存的堆栈，这是实现具有可扩展服务器的响应客户端的最佳方法。

---

笔记

• 使用方法1——我的500mb dyno（heroku服务器）内存不足

• 我希望无论使用哪种方法，我都将使用

• graphql服务器主要是为我自己的前端服务

---

如果服务器内存不足，可能是时候升级了。如果现在内存不足，想象一下当多个用户访问端点时会发生什么

解决这个特定问题的唯一其他方法是将查询分解为几个较小的查询。但是，您提出的方法存在以下几个问题：

• 最终，您的服务器和数据库将受到更多请求的冲击
• 根据是否需要立即呈现请求的数据，加载UI可能需要更长的时间
• 当您的一个请求失败时处理该场景，或者尝试重试失败的请求，可能是一项挑战

您已经建议添加分页，我认为这将是一种更好的方法，可以将单个大型查询分解为较小的查询。分页不仅有助于改善用户体验，而且通过对页面大小施加限制，可以有效地对给定查询的大小施加限制

---

另一个你可以考虑探索的选择就是使用。这个实验性的特性是专门为昂贵的查询而添加的。通过使

Note

类型上的一个或多个字段延迟，您可以有效地在最初为它们返回null，并且在它们最终解析后，它们的值将在第二个“补丁”响应中发送下来。这对于解析成本较高的字段非常有效，但对于返回大量数据的字段也可能有帮助。

您的问题有点不清楚。。。这里的假设是，在第二种方法中，您提出一个请求，查询

注释

，然后每个返回的id提出一个请求，这一次请求

注释

字段？同时询问“最佳方法”会使这个问题变得广泛，并受到意见的影响。提供一些标准会有帮助。除了服务器上的内存不足之外，您还需要解决其他问题。与其问“最好的方法是什么”，不如问哪种方法可以帮助我实现x、y和z？@DanielRearden——是的，方法2要求每个返回的id都有一个请求。我试图编辑问题，为其添加更多参数

type Query {
  note(id: ID!): Note
  notes(input: NotesQueryInput): [Note!]!
}

type DatedId {
  date: DateTime!
  id: ID!
}

type Query {
  note(id: ID!): Note
  notes(input: NotesQueryInput): [DatedId!]!
}