[RFC] Union types can implement interfaces

[derek-miller]

Problem
The spec, as it is currently, is ambiguous when defining how a union type should be handled when used to fulfill an interface.

An object field type is a valid sub‐type if it is an Object type and the interface field type is either an Interface type or a Union type and the object field type is a possible type of the interface field type.

Due to this, implementations of the spec do not allow the use of a union to fulfill an interface even though all members implements said interface. See issue graphql-js #1488.

Solution
A union should be considered an implementation of an interface if and only if each member type in the union implements said interface.

Examples
Consider the following schema:

type Query {
  test: MyConnection
}

interface Node {
  id: ID
}

interface Connection {
  nodes: [Node]
}

type NodeA implements Node {
  id: ID
}
type NodeB implements Node {
  id: ID
}
union MyNode =
  | NodeA
  | NodeB

type MyConnection implements Connection {
  nodes: [MyNode]
}

The above schema fails validation as MyNode does not directly implement Node even though all members do.

Concerns
I'm not aware of any concerns if this change was approved as it is additive and fixes an ambiguity in the spec. Existing schema would remain unaffected.

There may be issues unknown to me due to my incomplete understanding of the entire spec, so let me know if I missed anything.

[rmosolgo]

🤔 As a library author, I'm interested in keeping the language as simple as possible. In noticed an interesting mismatch between interface Node and union MyNode. In this trivial example, wouldn't it be a suitable solution to change union MyNode to be interface MyNode? Then what ever shared fields you needed to express could be added to MyNode.

Or, are there other cases where using an interface instead isn't a suitable solution?

[derek-miller]

@rmosolgo That would not work in the case where you have many implementations of your proposed MyNode interface, but only wanted to support returning a subset of those in a particular connection. The schema that I am working on where I hit this limitation has ~20 nodes and only a few of them are available at a time through a connection interface.

[rmosolgo]

Oh, so you want to specify a subset of objects which might be present at a certain point in the query, similar to a union? How about using several different interfaces, one for each applicable scenario? For example, interface MyNodeFromXConnection (where XConnection is a "particular connection" with a subset of objects as its possible return types). Then, objects could implement each applicable type: type X implements MyNode, MyNodeFromXConnection vs type Y implements MyNode (but not the XConnection-specific one). That would give you specific subsets for certain contexts.

It moves the complexity of this use case from the language specification to the application, but it might be a way to test the viability of your proposal!

Even if my imagined implementation is wrong, is that the kind of behavior you're looking for?

[leebyron]

I noticed that in your example, Connection is not being used anywhere, and removing it should result in a valid schema:

type Query {
  test: MyConnection
}

interface Node {
  id: ID
}

type NodeA implements Node {
  id: ID
}
type NodeB implements Node {
  id: ID
}
union MyNode =
  | NodeA
  | NodeB

type MyConnection {
  nodes: [MyNode]
}

Is this sufficient to solve your problem? Or is there a circumstance where a field returns a Connection interface type directly and not a specific Object type?

[derek-miller]

Our schema is rather large and we have several connection types. The purpose I originally had for the Connection interface is to enforce consistency across them. With that said, I do not want to stress my example and find alternative solutions in this issue, but rather have a discussion about how the spec should define this situation. I believe the spec should definitely state how this should be handled so there is no ambiguity or incorrect implementations.

[derek-miller]

Also I want to point out that I hit the same issue when having an Edge interface as so:

interface Connection {
  nodes: [Node]
  edges: [Edge]
}

interface Edge {
  node: Node
  # cursor, textMatches, etc
}

Again, @leebyron 's workaround will work if we remove the Edge interface, but pretty soon you start losing the power of a type system.

[leebyron]

Another suggestion would be to move the union to the connection types instead of the node types:

union MyConnection =
  | ConnectionA
  | ConnectionB

type ConnectionA implements Connection {
  nodes: [NodeA]
}

type ConnectionB implements Connection {
  nodes: [NodeB]
}

The reason for the invalidation is because union types can expand over time. While the members of the union type may happen to each be valid, future evolution of that union type may later cause an inconsistency.

If this continues to be limiting, another suggestion for an RFC would be to attempt to change the schema validation rules so that each member of the union is compared to the expected interface type rather than the union itself being compared. In other words, a union MyNode can be said to implement interface Node IFF each member type in MyNode implements interface Node.

[derek-miller]

a union MyNode can be said to implement interface Node IFF each member type in MyNode implements interface Node

This is exactly what I was suggesting graphql-js #1488, but it was declined because the spec did not explicitly cover this case and they suggested I open an issue here first.

[leebyron]

Great - I'd suggest taking a look at https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md#contributing-to-graphql-libraries which is hopefully helpful in guiding you towards next steps if you'd like to champion this effort

[derek-miller]

I am willing to champion this change. Let me know what I need to do to progress this to the proposal stage.

[derek-miller]

@leebyron I updated the issue description. Let me know what the next steps are. It is not clear from the contributing file if the champion is/should be the one to open the PR with the changes to the spec. I can make an attempt at it if necessary.

[derek-miller]

@leebyron Any update on how to move this forwards?

[derek-miller]

@leebyron, Can I get an update on this issue?