How to reuse Interfaces implementation in Apollo Federation?

I’m misunderstanding how Apollo Federation works, so it would be nice to get some help with this.

I’m trying to define an interface and implement the functionality in the same service, that way the other services can just delegate the query logic to the service that really cares about it. This is how I’m trying to define it:

Giving the following sub-graphs.

# Multimedia sub-graph

type Asset {
  url: String!
}

# Multimedia subgraph should implement
# the "assets" resolver; that way many
# types could delegate the functionality
# to this service resolver.
interface AssetOwner {
  id: ID!
  assets: [Asset]
}

# Accounts subgraph

type User implements AssetOwner {
  id: ID!
  name: String!
  # This should be only informative. The Apollo Federation
  # delegate this to the multimedia service.
  assets: [Asset] @external
}

It looks that I’m thinking about it in the wrong way, but this would be useful for adding functionality to many services without building the “Multimedia sub-graph” again for each type.

Do you have any advice on how I should implement this functionality?

An important principle of Federation is that each subgraph must be a valid GraphQL schema independent of other subgraphs. In your example, the Accounts subgraph can’t define that User implements an interface it doesn’t know about. But you can still make your example work:

Accounts subgraph

type User @key(fields: "id") { # doesn't care about the AssetOwner interface
  id: ID!
  name: String
}

Media subgraph

interface AssetOwner {
  assets: [Asset]
}

extend type User implements AssetOwner @key(fields: "id")  {
  id: ID! @external
  assets: [Asset]
}

However, it’s not clear to me why you have the AssetOwner interface. If you’re adding the interface because you’re trying to enforce a standard shape, I would recommend against that—it add complexity without benefiting the consumers of your graph.

But maybe you left this out of your example?

Media subgraph

type Asset {
  url: String
  owner: AssetOwner # could be a User, but could be other types
}

If that’s the case, you’re might run into an issue I filed a while ago: federation: queries for interface types require knowledge of concrete implementations · Issue #336 · apollographql/federation · GitHub.

Your media subgraph will need to know the concrete type of the AssetOwner interface. It won’t be able to simply return { id: "userid" } and expect the query planner to join this data with other subgraphs. This is a very challenging problem to solve, but it’s definitely on our list of things to tackle with Federation 2.

Hope this helps!