Component(s)
router
Is your feature request related to a problem? Please describe.
Custom router modules can run during request handling, but they currently cannot access the composed router schema from the request context.
That makes schema-aware modules harder to build. A module can inspect the request document, but without the composed schema it cannot reliably reason about runtime types, overlapping fragments, or whether the same response name maps to the same field or not.
One concrete example is a query rewrite module. This looks a bit odd, but it is something we already accept in the old system, so we need to preserve that behaviour.
scalar ISBN
interface Product {
isbn: ISBN!
}
interface SearchResult {
identifier: String!
}
type Book implements Product & SearchResult {
isbn: ISBN!
identifier: String!
}
type CD implements Product & SearchResult {
isbn: ISBN!
identifier: String!
}
type GiftCard implements SearchResult {
identifier: String!
}
type Query {
search: [SearchResult!]!
}query {
search {
... on Product { identifier: isbn }
... on SearchResult { identifier }
}
}For Book and CD, the Product branch does not need rewriting relative to itself, because both runtime types resolve identifier from the same field shape, isbn. The overlapping SearchResult branch is different, because it resolves identifier from another field. A module can only make that distinction safely if it has access to the composed schema.
Describe the solution you'd like
Expose the composed router schema through a small public API in router/core, available during request handling.
For example:
func WithRouterSchema(ctx context.Context, schema *ast.Document) context.Context
func RouterSchemaFromContext(ctx context.Context) *ast.Document
An alternative would be exposing it on RequestContext, for example:
RouterSchema() *ast.Document
I do not have a strong preference on the API shape. The important part is that request-time modules can access the composed schema through public API.
Describe alternatives you've considered
-
Only inspect the request document
This is not enough once module logic depends on schema information.
-
Load schema information separately inside the module
That duplicates information the router already has.
Additional context
This would help with modules that do schema-aware request rewriting, response rewriting, or request-time validation based on actual type information.
Component(s)
router
Is your feature request related to a problem? Please describe.
Custom router modules can run during request handling, but they currently cannot access the composed router schema from the request context.
That makes schema-aware modules harder to build. A module can inspect the request document, but without the composed schema it cannot reliably reason about runtime types, overlapping fragments, or whether the same response name maps to the same field or not.
One concrete example is a query rewrite module. This looks a bit odd, but it is something we already accept in the old system, so we need to preserve that behaviour.
For
BookandCD, theProductbranch does not need rewriting relative to itself, because both runtime types resolveidentifierfrom the same field shape,isbn. The overlappingSearchResultbranch is different, because it resolvesidentifierfrom another field. A module can only make that distinction safely if it has access to the composed schema.Describe the solution you'd like
Expose the composed router schema through a small public API in
router/core, available during request handling.For example:
An alternative would be exposing it on
RequestContext, for example:I do not have a strong preference on the API shape. The important part is that request-time modules can access the composed schema through public API.
Describe alternatives you've considered
Only inspect the request document
This is not enough once module logic depends on schema information.
Load schema information separately inside the module
That duplicates information the router already has.
Additional context
This would help with modules that do schema-aware request rewriting, response rewriting, or request-time validation based on actual type information.