Graphene-Django：连接，边缘和节点的概念

Question

我刚刚开始尝试使用graphene-django / GraphQL，并且对于为石墨烯-django引入的继电器库非常困惑。 在运行cookbook示例（使用我自己的模型实现它）并运行测试查询之后，在POST时，查询将转换为具有边和节点的奇怪嵌套对象。 这些是什么，他们在做什么？

{
  companies {
    edges {
      node {
       id
     }
    }
  }
}

Answer 1

节点

值得一提的是， Node是Facebook Relay规范 （不是GraphQL规范）的一部分。 但是，由于Relay和GraphQL之间的密切关联，大多数框架（包括Graphene）都实现了此规范。

Essentially Node是一个只实现ID字段的接口，它是一个对象的全局唯一标识符。 ID被设计为不透明（典型的约定是base64('type:id') ），应用程序不应该尝试依赖此实现细节。

Node作为根查询的一部分公开，其中应用程序可以方便的方式查询具有已知ID实体，例如，重新获取，获取尚未获取的字段。

{
  node(id: ID!) {
    ... on User {
      id
      userId
      name 
    }
    ... on Company {
      id
      companyId
      owner: {
        userId
        name
      }
    }
    ...
  }
}

这提供了不具有定义查询点为每一个模型你暴露（例如方便message(messageId)或user(userId) 这也允许您在不遍历对象路径的情况下查询对象，例如

{
  user {
    friends {
      pages {
        name
      }
    }
  }
}

// vs

{
  node(id) {
    ... on Page {
      name
    }
  }
}

连接

与Node一样， Connection也是Relay规范的一部分，这些规范已经成为主流采用的方式。

乍一看， edges的概念似乎是多余的，但它确实解决了一些棘手的用例。 考虑需要公开像“朋友”这样的多对多关系，通常在带有连接表的数据库中实现。

+---------+         +------------+
| users   |         | friends    |
+---------+         +------------+
| user_id | <------ | left_id    |
| ....    |    \--- | right_id   |
+---------+         | created_at |
                    +------------+

现在通过在edge对象中公开friends.created_at ，可以很容易地显示“自[date here]以来的friends.created_at ”。

{
  user {
    friends {
      edges {
        created_at  <---
        user {
          id
          userId
          name
        }
      }
    }
  }
}

edges实质上定义了nodes之间的关系。

Answer 2

Atable和Btable之间的M2M关系必须由第三个链接（join）表ABLink ，该表必须至少有两个外键：

+------+------+------------+--------+  
| A_id | B_id | Created_at | Status |  
+------+------+------------+--------+  

对m2m说edge代表数据库中的这种链接（连接）表是否正确？ 那么查询就是：

{
  Atable {
    ABLink {
      edges {
        Created_at
        Status
        Btable {
          Btable_id
          Btable_column_1
          Btable_column_2
          ...
        }
      }
    }
  }
}