The GraphQL Spec recently added support for Interfaces implementing other Interfaces, and the GraphQL PHP implementation even more recently added support for this.

WPGraphQL should provide some common interfaces that can be implemented by other Interfaces.

Example

All connections in the graph currently return edges and nodes. The Type of Edge and Type of Node vary, but this is common to all connections, so we can provide a common Connection Interface.

Interface Connection {
  edges: [ ConnectionEdge ]
  nodes: [ node ]
}

Then, we can add slightly more specific Interfaces. For example, all connections that connect to Post objects (of any post type) are connections to ContentNodes, so we can have an Interface like so:

Interface ContentNodeConnection implements Connection {
  edges: [ ContentNodeConnectionEdge ]
  nodes: [ ContentNode ]
}

Then, connections to a specific Post Type could implement a more specific Connection:

Interface PostConnection implements ContentNodeConnection {
  edges: [ PostConnectionEdge ]
  nodes: [ Post ]
}

Then, we can have additional general interfaces such as:

Interface TermObjectToContentNodeConnection implements ContentNodeConnection {
  edges: [ ContentNodeConnectionEdge ]
  nodes: [ ContentNode ]
}

And then a specific implementation:

Type TagToPostConnectionEdge implements TermObjectToContentNodeConnection {
  edges: [ TagToPostConnectionEdge ]
  nodes: [ Post ]
}

Added Value

This adds value to both client and server developers by providing more clarity via Introspection and more specific ways to customize the Schema on the server.

Introspection

Currently it's difficult to determine all the connections in the graph, but if all connections implemented a common Connection interface, Introspection could enable consumers to easily know about all Connections by querying for all Types in the Schema that implement the Connection interface.

Currently, trying to find all connections via introspection is, well, interesting:

Server Customization

Having Broad and Specific Interfaces and Types will allow server developers extending the Schema and underlying behavior more precise control over how to hook into the Graph.

For example, let's say I wanted to add a custom filter too all connections. Perhaps something like page-based pagination arguments.

I could apply that to the Connection Interface, and all connections in the graph would then have these fields.

Or, if I wanted to add some edge data to all TermObjectToContentNode connections, I could target that Interface, or more precisely target the TagToPostObjectConnection to add edge data to just Tag->Post connections.