federation: resolveType of extended interface without knowledge of concrete type

[cmschuetz]

Our existing services and clients utilize the node interface for object resolution and I haven't been able to figure out a way to implement this with federation

Given the following services:

Product Service

const typeDefs = gql`
  interface Node {
    id: ID!
  }

  type Product implements Node @key(fields: "id") {
    id: ID!
    status: String
  }
`

const resolvers = {
  Product: {
    __resolveReference({ id }) {
      return { id, status: 'in_stock' }
    },
  },
}

Node Resolution Service

const typeDefs = gql`
  interface Node @key(fields: "id") @extends {
    id: ID! @external
  }

  extend type Query {
    node(id: ID!): Node
  }
`

const resolvers = {
  Node: {
    __resolveType(object) {
      return object.__typename
    },
  },
  Query: {
    node(_, args) {
      const [__typename, decodedId] = Base64.decode(args.id).split('-')
      return { __typename, id: decodedId }
    },
  },
}

I am unable to lookup a product via the node field with its encoded id. Intuitively, this makes sense because the node resolution service is unaware of any types returned from __resolveType. How feasible would it be for __resolveType to allow for arbitrary types if it's extended?

Or am I thinking about this problem in the wrong way - have there been any other ideas for implementing the node interface with federation and gateway?

[victorandree]

I've thought a bit about this problem, too. Here's my 2 cents.

Federated service should still work standalone, which your Node resolution service cannot possibly do. This is because its schema doesn't have any types for the Node interface. For it to run as a standalone service, it should contain all the possible types of Node, marking them all as extend type Product. I.e., your Node resolution service would then be:

const typeDefs = gql`
  interface Node @key(fields: "id") @extends {
    id: ID! @external
  }

  type Product @key(fields: "id") @extends {
    id: ID! @external
  }

  extend type Query {
    node(id: ID!): Node
  }
`

const resolvers = {
  Node: {
    __resolveType(object) {
      return object.__typename
    },
  },
  Query: {
    node(_, args) {
      const [__typename, decodedId] = Base64.decode(args.id).split('-')
      return { __typename, id: decodedId }
    },
  },
}

However, this will mean that your Node resolution service must know of every type, and that it will resolve nodes which might not exist. The latter may be considered a feature, the former leads me to thinking that Node resolution should be part of the gateway (which anyway knows of every type). To my knowledge, there's no support for schemas which are only part of the gateway.

You should be able to construct your Node resolution service as a service in the gateway, though. For example, you can extend ApolloGateway to override loadServiceDefinitions or createSchema. Once all other services are loaded, it should be possible to dynamically create the Node resolution service in the gateway only.

[victorandree]

Minimal working example: https://github.com/victorandree/apollo-federation-relay (see TODO)

[tot-ra]

Thanks a lot, this example helped.

@queerviolet any chance to have node query supported be moved into apollo server natively to avoid extra network hop just to resolve references?