Proposal: Allow interfaces to implement other interfaces

[mike-marcacci]

This proposal expands upon the ideas described in #776.

I'd like to suggest that GraphQL be expanded to allow an interface to implement another interface. Together with #776, this would allow for higher order interfaces and open the door for frameworks and tooling to describe their requirements in GraphQL, which would be implemented in userland interfaces and types.

Here's a (very contrived) example borrowed from #776 and expanded upon to show how heirarchies would exist:

interface Pet {
	id: !ID
	sex: Sex
	name: String
	mother: Pet
	father: Pet
}

interface Equine implements Pet {
	id: !ID
	sex: Sex
	name: String
	mother: Pet
	father: Pet
	hands: Float
}

type Horse implements Equine {
	id: !ID
	sex: Sex
	name: String
	mother: Horse
	father: Horse
	hands: Float
}

type Donkey implements Equine {
	id: !ID
	sex: Sex
	name: String
	mother: Donkey
	father: Donkey
	hands: Float
}

type Mule implements Equine {
	id: !ID
	sex: Sex
	name: String
	mother: Equine
	father: Equine
	hands: Float
}

What's important here is that in a context where we generically have Pets, each pet's father is only guaranteed to be a Pet. When we know we have a Mule, though, we know that its father is an Equine.

With these two features, tools which currently depend on schema conventions (like the Relay specs) could codify their requirements with GraphQL.

A Real-World Case

I have been working on a system which allows offline, concurrent modifications to versioned documents. The problem and solution are very generic, but the current state of the GraphQL type system doesn't allow me to describe these general-purpose shapes. Much like the Relay team had to define a convention for any type ending in Connection, I have an internal spec describing any type with a name ending in Object, Entity, and Change. So, for example, I have a HikeObject, HikeEntity, and HikeChange; I also have a ClimbObject, ClimbEntity, and ClimbChange.

I've found myself wishing I could use the GraphQL type system to describe these requirements, and because the current spec is
so close, I find myself thinking of the schema in these terms.

This and #776 would make that possible, and bring GraphQL's type safety to tools that solve generic problems with GraphQL.

EDIT: Also, just to point out before someone makes this assumption from the title: this proposal does NOT bring with it any kind if inheritance, and should be completely backward-compatible with the current spec.

[mike-marcacci]

I have moved this to graphql/graphql-spec#295 hoping it will reach the right audience.