GraphQL 分页：游标与偏移量答案

【问题标题】：GraphQL pagination: cursor vs offsetGraphQL 分页：游标与偏移量
【发布时间】：2019-01-18 14:07:13
【问题描述】：

我们必须重建一个基于 REST 服务的后端应用程序，并且由于我们在服务中有很多嵌套级别，我们决定创新并尝试 GraphQL。

我们开始做一些简单的事情，项目看起来很有希望，但是我们开始面临现实世界的问题，比如分页。在 REST 中，分页方法很简单，我们使用带有一些参数的 GET 方法，例如 pageSize 和 pageNumber（或 offset），并构建 sql 查询来执行此分页。

在 GraphQL 中，我们使用相同的方法解决问题，例如使用以下查询：

users(size:5 offset:2) {
  id
  name
}

这种方法看起来很容易实现，但是在深入研究之后，我们发现实现它的“最佳”模式是连接模式，查询看起来像这样：

users(first:2) {
  totalCount
  edges {
    node {
      name
    }
    cursor
  }
  pageInfo {
    endCursor
    hasNextPage
  }
}

我们的数据保存在关系数据库中，因此我看不出游标有什么帮助（除非我使用自动增量 ID？）。

为什么推荐使用这种复杂方法而不是简单方法？还有什么 cursor 和 endCursor 将存储？我在学习过程中是否有误解？

【问题讨论】：

【解决方案1】：

Connection 规范最初是为 Relay（Facebook 的 GraphQL 客户端）创建的。它后来发展了自己的生命，现在被认为是最佳实践，无论客户如何。但是（这是一个巨大的但是），它肯定不能很好地映射到每个用例。

如果您看到实现Connection 分页样式的价值，您有两个选择：

1) 将after 视为偏移量（意味着将传递一个数字），并将first 视为限制：

SELECT * FROM ORDER BY timestamp OFFSET $after LIMIT $first

before 和 last 相同，只是方向不同。

2) 另一种方法是将after/before 视为排序列的最后看到的值（因此将传递实际（混淆的）值）：

SELECT * FROM ORDER BY timestamp WHERE timestamp > $after LIMIT $first

也就是说，如果您没有从 Connection 方法中受益，请随意忽略它。特别是如果您甚至不使用 Relay 作为客户端。这是一个完全可选的事情，不应该被硬塞到不属于它的地方。

【讨论】：