Algebraic interface types

[charypar]

I might be thinking about this wrong, but it feels really useful to be able to define a union of interfaces as a type. Alternatively, it would be nice to be able to supply multiple interfaces as a field type.

What I'm thinking of as a use case is a sort of type composition. Let's say I have an interface

interface Image {
  src: String
}

which represents an image I can display. Some images are stand-alone and I can link to them as a page, but other things share that capability. So I have another interface

interface Linkable {
  url: String
}

Now let's say that all users have profile pictures which are linkable. I'd like to be able to declare something like this

type User {
   profilePicture: Image + Linkable
}

When resolving such type, the only requirement is for the interfaces not to contain the same attributes. From there it should be entirely possible to find the defining interface for each attribute and then the implementing type based on interface type resolution.

Are there any plans for supporting this kind of thing or am I missing something that makes the implementation really hard or impossible?

[rmosolgo]

Interesting, do you think any other types could be "summed"?

[charypar]

I suppose Object types could? Although that doesn't seem as useful?

[rmosolgo]

PostType + CommentType seems like it should be DocumentInterface

[leebyron]

This is pretty interesting, and definitely something worth pursuing in future versions of the spec.

Currently, when we run into a case like this, we just define a new interface that's the manually summed interface, and use that as well.

[leebyron]

@rmosolgo - Interfaces are the only types that could be summable. Summing two unions doesn't really make sense: it doesn't lend to any change in query expressiveness and you could just define a new union if more types are possible. Summing two object types also doesn't make sense as object types are concrete (like classes in OO land).

[rmosolgo]

i'm with ya, that's what i was angling for, making one type "summable" doesn't seem like a great fit when interfaces already exist for exactly (er, almost) that purpose

[charypar]

@leebyron Would it be useful if I tried to do it for the JS implementation, or would you rather have the spec first?

[leebyron]

I think this is something we need to discuss at the spec level first. We will probably punt on it for the first version of the spec, but I want to leave room for discussion

[charypar]

Shall I open the same issue on the spec repo then?

[leebyron]

Sure

[leebyron]

It would also help if you include some concrete (non contrived) use cases you're trying to support to help work through useful discussion

[charypar]

@leebyron added to to graphql/graphql-spec#48.

[leebyron]

Closing here in favor of graphql/graphql-spec#48.