- Pass request arguments for external resolves across subgraphs
For example
Mode : Federated
Subgraphs: A, B
Subgraph A schema & query definitiontype 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’ : ASubgraph 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