Reuse named fragment in subgraphs even if they only apply partially

[pcmanus]

The focus of the code reusing fragment has been thus far on making that if a given named fragment can be used in a given selection set, then the code finds it. But in practice, the named fragments we try to reuse are those of the input query, so defined against the supergraph API schema, while we're trying to reuse them on subgraph fetches, so the fragment may be defined on a type that a subgraph does know, or request fields the subgraph does not define.

Currently, when asking if a given named fragment can be used against a given subgraph, we only keep fragment that fully apply to that subgraph (that is, only if everything the fragment queries exists in the subgraph).

This does limit the usefulness of named fragment reuse however, as one of the point of federation is that each subgraph defines a subset of the full supergraph API.

This commit improves this by instead computing the subset of each named fragment that do apply to a given subgraph, and define the fragment as only that fragment for the subgraph.

Note that it does so, this commit do not try reusing a named fragment against a subgraph if the subset of the fragment on the subgraph comes to only a single leaf field. This avoids spending time trying to reuse a fragment that ends up being just:

fragment MySuperFragment on X {
  __typename
}

or even:

fragment MySuperFragment on X {
 id
}

as those aren't productive (the goal of fragment reuse is to try to make the subgraph fetches smaller, but it is small to just request id, even 10 times, than to request 10 times ...MySuperFragment).

[netlify]

👷 Deploy request for apollo-federation-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	f4172d4

[changeset-bot]

🦋 Changeset detected

Latest commit: f4172d4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@apollo/query-planner	Patch
@apollo/federation-internals	Patch
@apollo/gateway	Patch
@apollo/composition	Patch
@apollo/query-graphs	Patch
@apollo/subgraph	Patch
apollo-federation-integration-testsuite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[dariuszkuc]

Looks good. Left few nits related to comments.

[dariuszkuc]

Suggested change

	// F1 reduces to nothing, and F2 reduces to just __typename so we should keep them.
	// F1 reduces to nothing, and F2 reduces to just __typename so we shouldn't keep them.

[dariuszkuc]

Suggested change

	// to that particular subgraph. And there is a few sub-cases where that subset is such that we basically need or
	// to that particular subgraph. And there are a few sub-cases where that subset is such that we basically need or

[dariuszkuc]

Suggested change

	// As we check inclusion, we ignore the case where the fragment queries __typename but the subSelection does not.
	// The rational is that querying `__typename` unecessarily is mostly harmess (it always works and it's super cheap)
	// so we don't want to not use a fragment just to save querying a `__typename` in a few case. But the underlying
	// context of why this matter is that the query planner always request __typename for abstract type, and will do
	// so in fragments too, but we can have a field that _does_ return an abstract type within a fragment, but that
	// _do not_ end up returning an abstract type when applied in a "more specific" context (think a fragment on
	// an interface I1 where a inside field returns another interface I2, but applied in the context of a implementation
	// type of I1 where that particular field returns an implentation of I2 rather than I2 directly; we would have
	// added __typename to the fragment (because it's all interfaces), but the selection itself, which only deals
	// with object type, may not have __typename requested; using the fragment might still be a good idea, and
	// querying __typename needlessly is a very small price to pay for that).
	// As we check inclusion, we ignore the case where the fragment queries __typename but the subSelection does not.
	// The rational is that querying `__typename` unecessarily is mostly harmless (it always works and it's super cheap)
	// so we don't want to not use a fragment just to save querying a `__typename` in a few cases. But the underlying
	// context of why this matters is that the query planner always requests __typename for abstract type, and will do
	// so in fragments too, but we can have a field that _does_ return an abstract type within a fragment, but that
	// _does not_ end up returning an abstract type when applied in a "more specific" context (think a fragment on
	// an interface I1 where a inside field returns another interface I2, but applied in the context of a implementation
	// type of I1 where that particular field returns an implementation of I2 rather than I2 directly; we would have
	// added __typename to the fragment (because it's all interfaces), but the selection itself, which only deals
	// with an object type, may not have __typename requested; using the fragment might still be a good idea, and
	// querying __typename needlessly is a very small price to pay for that).