facebook - 在您的 graphql 模式中连接边和节点的原因是什么？

Question

我正在尝试了解实现 Relay Cursor Connections Specification 的更复杂的 graphql api

如果您查看下面我在 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
    } 
  }
}

请注意它有字段 edges 和 nodes。

为什么github的api里多了一个叫做nodes的字段？为什么他们不直接使用边缘字段，因为你可以从边缘获得相同的数据？这只是为了方便吗？

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 时间的最小节省，而且可能比它的值(value)更麻烦。

我自己过去曾在 GraphQL 端点中实现过游标，一旦了解了方法，实际生成游标并不是那么困难。这只是序列化一些关键信息的问题。还可能值得注意的是，一旦您同时提供 (A->conn->edge->B 和 A->conn->B) 是非常简单的已经创建了 Edge 类型。

因为我不在 Github 工作，所以我不能告诉你确切的意图是什么。但是，我绝对认为这是第一个原因……只是为了方便开发人员。