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
          ...
        }
      }
    }
  }
}