8

我刚刚开始尝试使用 graphene-django/GraphQL，并且对 graphene-django 引入的中继库感到非常困惑。在运行完食谱示例（使用我自己的模型实现）并运行测试查询后，在 POST 后，查询被转换为带有边缘和节点的奇怪嵌套对象。这些是什么，他们在做什么？

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

2 回答 2

8

节点

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

本质上Node是一个只实现一个ID字段的接口，它是一个对象的全局唯一标识符。IDs 被设计成不透明的（典型的约定是 to 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 |
                    +------------+

现在可以通过friends.created_at在边缘对象中显示来轻松显示“自 [date here] 以来的朋友”。

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

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

于 2017-07-28T09:07:39.197 回答
0

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

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

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

{
  Atable {
    ABLink {
      edges {
        Created_at
        Status
        Btable {
          Btable_id
          Btable_column_1
          Btable_column_2
          ...
        }
      }
    }
  }
}
于 2018-02-21T20:30:30.027 回答