我们必须基于REST服务重建后端应用程序,并且由于我们在服务中具有许多嵌套级别,因此我们决定进行创新并尝试GraphQL。
我们开始做简单的事情,该项目看起来非常有希望,但是我们开始面临现实问题,例如分页。在REST中,分页方法非常简单,我们使用GET方法以及一些参数,例如pageSize
和pageNumber
(或offset
),并构建sql查询来执行此分页。
在GraphQL中,我们采用相同的方法来解决问题,例如使用以下查询:
users(size:5 offset:2) {
id
name
}
这种方法看起来很容易实现,但是在更深入地研究后,我们发现实现这种“最佳”模式是Connection one,查询看起来像这样:
users(first:2) {
totalCount
edges {
node {
name
}
cursor
}
pageInfo {
endCursor
hasNextPage
}
}
我们的数据保存在关系数据库中,因此我看不到游标如何提供帮助(除非我是否使用自动增量ID?)。
为什么推荐这种复杂的方法而不是简单的方法?还有游标和endCursor将存储什么?我在学习道路上误解了吗?
答案 0 :(得分:2)
Connection
规范最初是为Relay(Facebook的GraphQL客户端)创建的。后来,它发展了自己的生活,无论客户是谁,现在都被视为最佳实践。但是(这是一个很大的 but ),它绝对不能很好地映射到每个用例。
如果您发现实现Connection
分页样式很有用,则有两种选择:
1)将after
视为偏移量(表示将传递数字),并将first
视为限制:
SELECT * FROM ORDER BY timestamp OFFSET $after LIMIT $first
before
和last
相同,只是方向不同。
2)另一种方法是将after
/ before
视为sort列的最后一次看到的值(这样,将传递实际的(混淆的)值):
SELECT * FROM ORDER BY timestamp WHERE timestamp > $after LIMIT $first
也就是说,如果您没有从Connection
方法中受益,请随时忽略它。特别是如果您甚至没有使用Relay作为客户端。这是完全可选的,不应该在它不属于任何地方的情况下shoe之以鼻。