Feature Request: Allow interfaces to resolve to other interfaces

[SleeplessOne1917]

Suppose I have the following schema:

interface Node {
    id: ID!
}

interface Product implements Node {
    id: ID!
    price: Float!
}

type Food implements Product & Node {
    id: ID!
    price: Float!
    expirationDate: String
}

I'd like to set up my resolvers for Node and Product like so:

const Node = {
    __resolveType(node) {
        if (node.price)
            return 'Product';
        return null;
    }
}

const Product = {
    __resolveType(product) {
         if (product.expirationDate)
            return 'Food'
        return null;
    }
}

In the current implementation of Apollo Server, the Node resolver will result in an error because it resolves to Product, an interface type. This is despite the fact that Prodcut goes on to resolve to a concrete type. To make this work, the developer has to add logic for resolving Food to both the Product and Node resolver. This introduces code duplication, which becomes worse as more implementations of Product are added, and especially if other interfaces that implement Node and have own implementations are introduced.

I propose that it would be easier for the developer to maintain their resolvers if resolution of interface types could be chained. For the Node resolver in the example, that would mean when it resolves to Product, it goes on to use Product's __resolveType to resolve to the concrete type Food.

[glasser]

This makes sense as a desire. That said, I think this is implemented in graphql-js rather than in Apollo Server (by way of @graphql-tools/schema which puts __resolveType methods onto graphql-js objects). It happens in completeAbstractValue and ensureValidRuntimeType in execute.ts. I can imagine allowing an iterative approach here... you wouldn't even have to worry about infinite loops as long as the requirement is that the returned typename implements the given typename and doesn't equal it (because the implementation graph is acyclic, I think). @IvanGoncharov do you think this would be a reasonable feature request for graphql-js?

[SleeplessOne1917]

I was looking at the code for execute.ts and found one potential difficulty: GraphQLAbstractType doesn't seem to differentiate between interfaces and unions. If my suggested change was implemented, that would also allow unions to resolve to abstract types and, to my knowledge, that's against the GraphQL spec. Scratch that. There's an isInterfaceType and isUnionType defined in types/definitions.ts that I could use.

[trevor-scheer]

Closing here since I see the requested issue was opened against graphql-js