In the WPGraphQL Schema, you will note that many queries have a shape consisting of
This shape comes from the Relay Connections Specification. While WPGraphQL doesn’t have to be used with the Relay client – it can be used with any client – the principles laid out by the Relay spec solve many common problems.
GraphQL itself makes almost no declarations on what shape a GraphQL Schema should have. The freedom is nice, but can also lead to trouble in a naive schema design.
Edges and Nodes give a space to put data that exists in the context of specific connections where requested data isn’t a property of either node in the connection, but rather a property of the connection between the nodes.
A good example of this is pagination data. Consider the following query.
When asking for a list of items (nodes), it’s a common need to be able to paginate and ask for more items.
A naive Schema may have added a root field
posts that simply returned a list of
Post objects, but that would leave no room for providing the client with pagination info.
In the above query, we see that by nesting the fields, we open up space to provide pagination information, and we also can
The cursor is not a property of the Post node, as the post could be a result of any number of different queries, and the cursor would be different based on the query it’s part of. The cursor is
edge data, as in, it’s a property of the post (node) in
If the cursor were exposed as a property of the node, a caching client such as Apollo would constantly be overriding the cursor and confusing the cache. By exposing it on the edge, it can be cached in relationship to the query, not as a property of the node itself.
Edges and Nodes are hard to grasp, and at first their shape seem overkill and unnecessary, but as you use GraphQL to build applications, you quickly realize their value.
You can read more about Connctions here: