在graphql架构中连接中有边和节点的原因是什么？

Question

我试图了解更复杂的graphql apis,它实现了Relay Cursor Connections Specification

如果你看一下我在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中有一个称为节点的附加字段？为什么他们不使用edge字段,因为你可以从边缘获得相同的数据？这只是为了方便吗？

Answer 1

如果我们查看公共连接实现的一般结构,通常会有以下内容: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工作,我无法告诉你究竟是什么意思.但是,我绝对认为这是第一个原因......只是开发人员的便利.

Answer 2

无论您如何处理,节点始终都是相同的.边缘是关于连接上下文中该节点的元数据,通常只是光标,但如果您的连接代表搜索查询,您还可以添加相关性分数等内容.这些数据不应存在于节点本身上,因为它在不同的上下文中没有意义.

术语:

1. 节点,代表一个实体.在由线连接的圆圈图中,这些是圆圈.
2. Edge,将两个节点连接在一起,可能包含元数据.在图中,这些是线.
3. 连接,节点的分页列表.在图中,这将是一组线.