Github GraphQL v4 API 嵌套分页（单个查询中不能跟随多个分页游标）

Question

让我们画一个假设的图片以供讨论。

假设一家大公司有 200 个组织，每个组织有 250 个存储库，每个存储库有 300 名贡献者。

假设我想构建一个回答问题的 GraphQL 查询：

将我帐户中所有组织的所有存储库的所有贡献者（及其权限）都给我。

显然，需要分页。

但是它目前的实现方式是为每个贡献者列表、每个存储库列表和每个组织列表提供一个分页游标。

因此，不可能通过跟踪单个分页游标来完成查询。

由于为一个组织/存储库组合与下一个组织/存储库组合的一个贡献者列表指定分页游标的歧义，我不清楚是否可以完成查询。

谢谢

Answer 1

您的初始查询结构如下所示（简化）：

query {
  organizations(first: 10) {
    repositories(first: 20) {
      contributors(first: 30) {
        name,
        privileges
      }
    }
  }
}

现在想象这个查询将返回单个分页游标。下一页应该是什么样子？

1. 接下来的 10 个组织（前 20 个存储库，前 30 个贡献者）
2. 相同的 10 个组织，但接下来的 20 个存储库（前 30 个贡献者）
3. 相同的 10 个组织，具有相同的 20 个存储库，但接下来的 30 个贡献者
4. 上述内容的一些疯狂组合

当您构建自己的 GraphQL API 时，您可以根据需要设计光标分页。但 GitHub API 必须服务于广泛的消费者，他们选择了非常灵活的模式设计，使客户端能够准确地获取他们需要的数据，而不会过度获取。但在某些情况下，可能需要额外的往返才能获取所需的所有数据。

让我们从前端的角度来看一下：

初始请求后，您将显示前 10 个组织，每个组织的前 20 个存储库，以及每个存储库的前 30 个贡献者。

现在用户可以决定他想要更多哪些数据：

• 加载更多组织，或者
• 为特定组织加载更多存储库，或者
• 为特定存储库加载更多贡献者

这些决定中的每一个都将导致使用 GitHub API 提供的游标之一进行简单的分页查询。不需要万能的分页光标。

（我非常怀疑，是否有一个 UI/UX 用例，你想一次对所有内容进行分页）

尽管在这种情况下，我想说 GitHub API 本身就非常适合。在我看来，一次性显示贡献者是不合理的200 * 250 * 300 = 15000000，因为从用户的角度来看，这太过分了。

让我们从后端的角度来看一下：

如果您想收集您所描述的数据以在后端服务器上进行分析、聚合或类似操作，并且您已经知道您需要所有数据，那么您可以通过提供大量的 来完全跳过分页first。（可能不适用于 GitHub 的 API - 据我所知，它们限制100每个分页的最大条目数）。

即使您被迫使用分页，您也可以缓存结果。当然，仍然需要数百次往返 GitHub API，但这可以是每晚运行一次的预定作业。

因为此时您已经编写了所有必要的代码，所以很容易实现某种部分刷新。例如，如果您知道“组织 13 的存储库 42”非常活跃，则您可以重新获取此特定存储库的数据（按需或以更短的时间间隔）并更新缓存。

我不知道你的具体用例，但只要你不需要（几乎）实时更新这个巨大的数据集，我会说 GitHub 的 API 足以满足大多数人的要求。