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

我试图理解更复杂的 graphql api 来实现继电器光标连接规范 https://facebook.github.io/relay/graphql/connections.htm

如果您查看下面我在github graphql api 浏览器 https://developer.github.com/early-access/graphql/explorer/

{
  repository(owner: "getsmarter", name: "moodle-api") {
    id
    issues(first:2 ) {
      edges {
        node {
          id
          body
        }
      }
      nodes {
        body
      }
      pageInfo {
        endCursor
        hasNextPage
        hasPreviousPage
        startCursor
      }
      totalCount
    } 
  }
}

注意它有字段edges and nodes.

为什么 github 在其 api 中多了一个名为“nodes”的字段？既然可以从边缘获得相同的数据，为什么他们不直接使用边缘字段呢？这只是为了方便吗？

如果我们查看公共连接实现的一般结构，您通常会看到以下内容： TypeA -> TypeAToTypeBConnection（通常是 TypeA 上的一个字段，其名称类似于typeBConnection) -> TypeAToTypeBEdge（通常是与名称连接的名称字段edges) -> TypeB（通常是边上的字段名称，名称为node)

A -> connection -> edges -> B

连接类型通常会有包含特定于整个连接的信息的字段，通常是寻呼信息、总计数等。

边缘类型通常具有包含特定于该连接但不是所有节点共有的信息的字段。在这种情况下最常见的字段是cursor它表示连接中节点的“位置”，它不是全局唯一 ID，而是返回连接中该位置的一种方法。

节点类型通常只是连接所采用的类型，不包含连接特定信息

就 github 的 API 而言，Edge 类型具有常用的实现方式cursor稍后可以在该连接中用作参考的字段。他们还有一个绕过的字段edge如果不需要光标，请输入。这就是为什么你会看到两者edges and nodes字段直接脱离连接类型。

要查看这些游标字段，您可以发送以下查询来查看我在说什么：

{
  repository(owner: "getsmarter", name: "moodle-api") {
    issues(first:2 ) {
      edges {
        cursor
        node {
          id
        }
      }
    }
  }
}

有关这种连接方式的更多详细信息，请查看此处：https://facebook.github.io/relay/graphql/connections.htm https://facebook.github.io/relay/graphql/connections.htm

编辑-附加响应：允许在连接处访问边类型和节点类型的目的至少有两个我能想到的原因。首先，为了方便那些使用 API 的人，当他们的用例不需要游标时。其次，可能存在一种情况，根据发送的查询，它们可能甚至不需要生成游标。第二个可能只能节省最少的 CPU 时间，并且可能会带来更多麻烦。

过去我自己在 GraphQL 端点中实现了游标，一旦您了解了如何实现游标，它们的实际生成并不是那么困难。这只是将一些关键信息序列化的问题。还可能值得注意的是，提供两者都非常简单（A->conn->edge->B and A->conn->B）一旦您已经创建了边缘类型。

由于我不在 Github 工作，所以我无法告诉你确切的意图是什么。然而，我绝对认为这是第一个原因……只是开发人员的便利。