我试图了解实现Relay Cursor Connections Specification
的更复杂的graphql apis如果您查看我在github graphql api explorer
上运行的查询{
repository(owner: "getsmarter", name: "moodle-api") {
id
issues(first:2 ) {
edges {
node {
id
body
}
}
nodes {
body
}
pageInfo {
endCursor
hasNextPage
hasPreviousPage
startCursor
}
totalCount
}
}
}
请注意,它包含边和节点字段。
为什么github在api中有一个名为nodes的附加字段?为什么他们不使用edge字段,因为你可以从边缘获得相同的数据?这只是为了方便吗?
答案 0 :(得分:10)
如果我们查看公共连接实现的一般结构,通常会有以下内容:
TypeA - > TypeAToTypeBConnection(通常是TypeA上的字段,名称为typeBConnection
) - > TypeAToTypeBEdge(通常与名称edges
连接时的名称字段) - > TypeB(通常是名称为node
的边缘上的字段名称)
A -> connection -> edges -> B
连接类型通常包含特定于整个连接的信息的字段,通常是分页信息,总计数等。
边缘类型通常包含具有特定于该连接但不是所有节点通用的信息的字段。在这种情况下,最常见的字段是cursor
,它表示连接中的节点“位置”,它不是全局唯一ID,而是返回连接中该位置的方式。
节点类型通常只是连接的类型,它不包含任何连接特定信息
对于github的API,Edge类型具有通常实现的cursor
字段,可以在以后用作该连接中的引用。在您不需要游标的情况下,它们还有一个绕过edge
类型的字段。这就是您直接在连接类型中看到edges
和nodes
字段的原因。
要查看这些光标字段,您可以发送以下查询以查看我在说什么:
{
repository(owner: "getsmarter", name: "moodle-api") {
issues(first:2 ) {
edges {
cursor
node {
id
}
}
}
}
}
有关此连接方式的更多详细信息,请查看此处:https://facebook.github.io/relay/graphql/connections.htm
编辑 - 其他回复: 在连接时允许访问边缘类型和节点类型的目的可能至少有两个我能想到的原因。首先,为了方便那些使用API的人,当他们的用例不需要游标时。其次,可能存在一种情况,根据发送的查询,它们可能不需要甚至生成游标。第二种可能是CPU时间的最小节省,并且可能比它的价值更麻烦。
过去我自己在GraphQL端点中实现了游标,一旦你克服了这些游标,它们的实际生成并不是那么困难。这只是序列化一些关键信息的问题。它也可能值得注意,一旦您已经创建了Edge类型,提供(A->conn->edge->B
和A->conn->B
)非常简单。
由于我不为Github工作,我无法告诉你究竟是什么意思。但是,我绝对认为这是第一个原因......只是开发人员的便利。
答案 1 :(得分:7)
无论您如何处理,节点始终都是相同的。边缘是关于连接上下文中该节点的元数据,通常只是光标,但如果您的连接代表搜索查询,您还可以添加相关性分数等内容。这个数据不应该存在于节点本身上,因为它在不同的上下文中是没有意义的。
<强>术语强>:
答案 2 :(得分:2)
它可能只是方便他们,因为他们可能有一些疯狂的查询,它减少了JavaScript中的对象查找。边缘还将包含cursor
属性以及node
属性,这些属性可能并非在任何地方都需要,因此具有顶级node
字段的另一个好处。
我还应该注意,边缘/游标约定强烈适应特定于中继的环境,以及基于游标的分页系统,您只能通过单个索引/页面移动。如果您希望创建一个更传统的分页系统,那么您就不必实现这种类型的分页。
打破游标分页的用例是客户想要跳转到第5页,并且在第1页上,因为游标不透明,所以在中继中不可能,并且是&#34的基础;其中&#34;在您目前所在的收藏中。
希望有所帮助!