Graphql Federated Best Practices for context + argument passing across subgraphs

  • Pass request arguments for external resolves across subgraphs

For example

Mode : Federated
Subgraphs: A, B
Subgraph A schema & query definition

type CustomType @key(fields: “customId”) {
customId ID!,
… # other fields
}
query {
getCustomType(String argA, String argB) : [CustomType]
}
Subgraph B schema & query definition
extend type CustomType {
customId : ID!, @external
fieldA: String, ## depends on argB
}

Questions:

  • Preferred way to pass argB to subgraphB query resolvers within GraphQL framework
  • Choices we internally discussed to enhance the customType to include argB as a separate field which would break abstraction concerns for customType, but argB is required mandatorily for query resolve call in subgraphB
  • Pass identical additional context across services

For example

Mode : Federated
Subgraphs: A, B
ClientRequest
HttpHeaders: ‘x-custom-header’ : A

Subgraph A schema & query definition

type CustomType @key(fields: “customId”) {
customId ID!,
… # other fields
}
query {
getCustomType(String argA) : [CustomType]
}

Subgraph B schema & query definition

extend type CustomType {
customId : ID!, @external
}

Questions:

  • Preferred way of passing identical contexts across subgraph. Request headers are not relayed completely from gateway to external resolve graphql calls, only the originating graphql server has the headers from client passed identically, in the particular case ‘x-custom-header’ header is passed only to service of subgraph A, but not to service of subgraphB