Skip to main content
Solved

'Edge' and 'Node' naming

  • 24 March 2022
  • 1 reply
  • 52 views

DanielJohnLevings
Practitioner

Hei!

In the current schema setup, I might make a query such as this:

The terms ‘edges’ and ‘node’ is a bit confusing to me. I’m not sure what they really mean in this context (I understand it from a graph db point of view, but its a bit confusing from other points.

 

I might expect something like this instead

{

  listAsset() {

    items {

      externalId

    }

    pageinfo {

      cursor, ...

    }

  }

}

 

Curious to hear your thoughts on this :)

Best answer by Kristian Aurlien

Great question, Daniel! 

 

The structure and naming of these types follow the GraphQL Cursor Connections Specification, which aims to "consistently handle pagination best practices with support for related metadata via a GraphQL server." 

 

While we don't currently add a lot of information on the edge types (they only contain the cursor and node fields), we envision that they will be useful for adding extra metadata in the future. 

 

One example of metadata that belongs on the edge types is data about a relationship (edge) between two objects (nodes). Say we want to model a time-limited flow between two assets:

(a1: Asset) -- [FLOWS_TO { startTime: 1648120612, endTime: 1648125620 }] → (a2: Asset)

 

The query could then look something like this:

{
  listAsset(externalId: "a1") {
    edges {
      node {
        externalId
        flowsTo {
          edges {
            startTime
            endTime
            node {
              externalId
            }
          }
          pageinfo {
            endCursor
            hasNextPage
          }
        }
      }
    }
  }
}

 

However, we have considered adding a convenience field for accessing the nodes when you don't have/need such information on the edges. This would probably look very similar to what you are suggesting:

{
  listAsset() {
    nodes {
      externalId
      ...
    }
    pageinfo {
      endCursor,
      hasNextPage
    }
  }
}

 

View original
Did this topic help you find an answer to your question?

Great question, Daniel! 

 

The structure and naming of these types follow the GraphQL Cursor Connections Specification, which aims to "consistently handle pagination best practices with support for related metadata via a GraphQL server." 

 

While we don't currently add a lot of information on the edge types (they only contain the cursor and node fields), we envision that they will be useful for adding extra metadata in the future. 

 

One example of metadata that belongs on the edge types is data about a relationship (edge) between two objects (nodes). Say we want to model a time-limited flow between two assets:

(a1: Asset) -- [FLOWS_TO { startTime: 1648120612, endTime: 1648125620 }] → (a2: Asset)

 

The query could then look something like this:

{
  listAsset(externalId: "a1") {
    edges {
      node {
        externalId
        flowsTo {
          edges {
            startTime
            endTime
            node {
              externalId
            }
          }
          pageinfo {
            endCursor
            hasNextPage
          }
        }
      }
    }
  }
}

 

However, we have considered adding a convenience field for accessing the nodes when you don't have/need such information on the edges. This would probably look very similar to what you are suggesting:

{
  listAsset() {
    nodes {
      externalId
      ...
    }
    pageinfo {
      endCursor,
      hasNextPage
    }
  }
}

 


Reply


Cookie Policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie Settings