Federation: Multi entity resolver interactions with @requires
#4,140 opened on Apr 23, 2026
Repository metrics
- Stars
- (10,737 stars)
- PR merge metrics
- (PR metrics pending)
Description
Hi,
I'm trying to design a federated graphql architecture in which entities can resolve @requires fields that take an array of objects, then resolve them in an efficient way without using the dataloaders pattern.
The key issue would be that if a subgraph is to declare a new field that requires other fields that are arrays, e.g.:
type Product @key(fields: "id") {
id: ID!
variations: [Variation!]! @external
bestPrice: Float! @requires(variations { price })
}
type Variation {
price: Float!
}
is there a way to resolve bestPrice for multiple products in one entity resolution function call without encountering the N+1 problem?
I've made multiple attempts using variations of explicit_requires, computed_requires, entity_resolver_multi and goField(batch: true) and shared the outcomes as of gqlgen@0.17.89 in this repo: https://github.com/tobby-s/multi-entity-tests
The examples are all runnable, there's a curl shared in the repo root to test on each of the examples to trigger debugging println lines to illustrate some points, etc.
In particular I'm looking for a way to resolve multiple fields of multiple representations of an entity type at once, while consuming all @required fields including complex object-array fields in one function scope, i.e. some function that has the signature []*model.Product -> []*model.Product.
Is there a combination of schema directives/gqlgen.yml config params that can achieve this?
If it's not currently possible, I'm willing to put in a bit of time to make a contribution to make this possible, but what would be the ideal way to do this from the code owners' perspective? e.g. should I ignore explicit_requires since it's meant to be deprecated (even though it's the closest available thing to a solution at the moment)?
Issues I've explored while looking into this:
- https://github.com/99designs/gqlgen/issues/3742 - I thought this might be a solution, but I tried the example given in the issue and it didn't have the internal functionality required (see the entityresolverexplicit + entityresolvermulti examples in the multi-entity-tests repo)
- https://github.com/99designs/gqlgen/pull/1709 - This adds the
@entityResolver(multi)functionality but the generated code only has access to the entity key fields and not the@requiredfields - https://github.com/99designs/gqlgen/pull/4040 - This adds the
@goField(batch)functionality but this works on a per-field level and doesn't let us optimise for resolving multiple fields from the same expensive call. Luckily the subgraph we are planning for is only responsible for one field per entity at the moment, however ideally there would be a way for us to do this across multiple fields as well.