Probably a limitation of GraphQL.
In GraphQL, your schema isn’t valid if it has references to things that don’t exist in its full schema, so you wouldn’t be able to start your child services in order to perform remote composition.
Federation is also not two-way; sure, the gateway sends requests to the child services, but the child services don’t actually know about the gateway. Making them require functionality that exists inside of the gateway causes them to depend on the gateway, which already depends on them in the first place, so you’d have a circular dependency between services.
Unless Apollo finds a way federation composes schemas in a way that solves this while also being fully compliant with the GraphQL spec, there’s not a whole lot to do. Using git submodules or a
common folder for shared type definitions and resolvers is a small price to pay when compared to the architectural overhaul of resolving partial schemas and circular dependencies.
Even doing something seemingly simple, like “have the gateway process these specific things” opens a very wide and deep can of worms. For example, what happens if you have thousands of references to a directive or enum across various schemas, and a custom resolver respectively? You’d have to make possibly thousands of requests at once back to the gateway to resolve them, which creates a ton of network traffic and also causes the gateway to be doing more work than any other service, creating a potentially huge bottleneck.
As a result, a single custom resolver being added to the gateway could clog up the pipes, causing your autoscaler to scale up massively, meaning that it potentially becomes an ordeal to add a custom resolver, rather than saying “here’s a common file/folder for these X services; if the algorithm is too slow we’ll update it”, but the bottleneck stays on the child service.
I agree that it would be nice to not have to have such duplicate definitions and then have to deduplicate them, too, but the scope of such a task and is large and vaguely defined, to the point where taking steps to mitigate certain issues might create an environment for unsustainable feature creep. I think that these solutions should definitely exist, though, but there would probably need to be a whole new API introduced into the gateway to allow users to perform arbitrary schema manipulations for such “vanity” purposes as this, allowing the GraphQL ecosystem to fill in certain gaps that are too large or have too many opinions to “succeed” at implementing.
If a winner emerges, it can be added to the docs or pulled into
@apollo/gateway if it’s deemed too much boilerplate.