Proposal: Allow interfaces to implement other interfaces

[mike-marcacci]

This proposal expands upon the ideas described in #294 (which ended up already being implemented).

I'd like to suggest that GraphQL be expanded to allow an interface to implement another interface. 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 #294 and expanded upon to show how hierarchies 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 would make that possible, and bring GraphQL's type safety to tools that solve generic problems with GraphQL.

[mike-marcacci]

As I've continued the think about this, I wanted to clarify a point:

If an interface implements another interface, it MUST specify compatible fields in its own fields list.

This keeps all the simplicity of the current system (with the total absence of inheritance, and a flat interface implementation strategy) while adding the functionality of chained interfaces.

[nicksrandall]

I also have a "real world" use case for this and would love to see this added to the spec. What are the concerns?

[stanishev]

@mike-marcacci, only a suggestion: would it be possible to consider using extends instead of implements?
I am relatively new to graphql, but I find that most devs coming from any language or environment think of interfaces extending other interfaces, while types and classes implement interfaces. I think this would apply even in the scenario above where you mention that interfaces down the chain MUST specify all fields in their own fields list.

[mike-marcacci]

Hi @stanishev! Thanks for the comment – I definitely thought about using this terminology, and considered how it might be interpreted by programmers of various languages. When writing this issue, I decided against extends to avoid the misconception that I was advocating for inheritance.

In fact, it's quite possible that there is a use-case for true inheritance (by which I mean applying the field definitions of one or more parents), while my use case simply needs the ability to describe a hierarchy. I would argue that extend is a different potentially-useful feature, in which a concrete type might define its fields by reference to other concrete types. I wanted to avoid misappropriating this word to describe a concept that's already fully contained by the implements keyword in GraphQL (albeit currently only for concrete types).

Also, I wanted to avoid bringing into the discussion the complexities of inference in general: In what order of precedence might a multi-parent inheritance effected? What happens when parents have non-identical (but potentially compatible) field types (type variance)? Can I "sub-class" a parent to have a non-compatible field type? etc...

All that said, if the GraphQL team chose to add this to the spec under the keyword extends, I would be more than happy to have it. I do think, though, that reusing implements here is a bit smaller of a request :)

[vergenzt]

Not sure how mixins/inheritance got involved, but could that discussion happen in a new thread if you'd like to advocate for it? Either of those concepts would be more complicated than what this issue proposes, and I'm very interesting in seeing this proposal added so would rather not see the discussion veer off.

(Mixins sound interesting, but the GraphQL team seems acutely interested in keeping the spec as simple as it can possibly be, and IMHO mixins are not simple.)

---

Any thoughts from the core team on this? Would you be open to a PR? I'd love to help @mike-marcacci out with this but wouldn't want to waste the effort if you think it's unlikely to be accepted.

[MatthewHerbst]

While this is being discussed, does anyone have a clean workaround that they are using?

[jwb]

I would also make use of this at Zillow, where our type system includes a hierarchy of property records, in which the most basic type is a PublicRecord, which is extended by a PropertyRecord (includes attributes added by Zillow systems), which in turn is extended by a PropertyListing (includes attributes added by an agent or owner).

Is anyone already working on a PR to incorporate this proposal into the spec?

[voxpelli]

@MatthewHerbst @jwb While I don't want to reintroduce mixins/partials as a solution to this issue, I do wanted to point you to graphql/graphql-js#703 (comment) and the solution I outlined there and the transpiler/polyfill I created to solve my need for making my schema more DRY by adding mixins/partials: https://github.com/Sydsvenskan/node-graphql-partials

(It's a solution that would also help in making heavy usage of interfaces manageable – ensuring all implementations are in sync with the fields defined)

@tylercrompton Did you create another issue for the mixin case? Would be good to link graphql/graphql-js#703 to that one if so

[jwb]

If mixin support were added, I would make use of it. I feel that enabling inheritance of interfaces is a basic feature of a type system and I need it more than I need mixins, since I can accomplish what I would use from mixins (minus inheritance) with code generation.