3

We are trying to implement Relay node query with Apollo federation. Since Apollo is not aware of Relay, we have to implement the node query in some service (Node Resolution Service)

interface Node {
  id: ID!
}

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

The trouble is that the Node resolution service is not aware of any of the implementation types as they are defined in other service subgraphs.

The Apollo Gateway sends the following request to the node resolution service

{node(id:"dHlwZUZyb21BU2VydmljZTox"){__typename ...on TypeFromAnotherService{id __typename}}}

The query validation fails as the service does not know anything about TypeFromAnotherService. We are able to implement the node query as we have the type encoded in the ID, but we do not know how to fix the validation.

  1. We can generate the schema dynamically based on the federated schema. This seems to be used here but feels cumbersome
  2. Switch-off the validation and trust Apollo GW validation. We do not like it and it seems that it is not possible in Netflix DGS which we use on backend.

Any ideas how to make Relay node query work with the federation?

Lukas
  • 13,606
  • 9
  • 31
  • 40
  • There is a new [issue](https://github.com/apollographql/federation/issues/1067) related to this – Lukas Oct 14 '21 at 11:42

3 Answers3

1

We solved it by implementing a standalone Node Resolver. It does the following:

  1. Inspects the query and generates the schema on-the-fly in case Apollo uses a type in a fragment. Node resolver basically adds TypeFromAnotherService to the schema.
  2. Node resolver extracts Type from the ID and generates the response.

We are thinking about open-sourcing the service, would anybody be interested?

Lukas
  • 13,606
  • 9
  • 31
  • 40
  • Sure, Apollo Client has its own way to cache the data but Relay global identifier pattern is also useful from the API alone perspective. It's a pity it is not addressed officially in the federation implementation. I would be interested if you came up with plug-and-play node resolver implementation for the gateway. – ssukienn Dec 15 '21 at 12:55
0

There are similar open issues on Apollo's GitHub repo for federation: https://github.com/apollographql/federation/issues/377 https://github.com/apollographql/federation/issues/1067

These discussions give some of the reasoning behind why it's an open issue and examples of how it could be worked around. In addition, this example can be used for mapping ids from nodes to entities but isn't a supported feature of Apollo: https://stackblitz.com/edit/nodemon-zbdwdj?file=README.md

If these don't work for your use case, I'd add feedback to the most relevant GitHub issue.

Kyle O'Brien
  • 150
  • 10
0

I had the same issue. I wanted both the benefits of Apollo Federation on my Backend and cache handling of Relay on my Frontend. The most straightforward way I could find is to make a Node service that IS aware of all Node types. With Apollo Federation that is relatively easy. I wrote a short article on how you can implement this if you are interested here!

Unfortunately, this means you need to add your Node types to another service to get caching to work. I’m hoping Apollo will release some sort of plugin or tooling to enable this in the Gateway.

Riley Conrardy
  • 392
  • 1
  • 9
  • 17