Federated schema checks
To learn about schema checks for non-federated graphs, see Schema checks.
Federation enables teams to work independently on implementing services without needing to coordinate on a monolithic schema. However, this increase in autonomy requires controls to ensure that teams respect defined dependencies ensure that graph composition succeeds.
In particular, along with validating overall schema changes against known operations, running
apollo service:check for a federated service will ensure that the overall graph still composes to a valid schema, and will output any violated dependencies if present.
With a federated graph, use the
apollo service:check command to validate individual service changes by adding the
When you run
apollo service:check on a federated service, Apollo Studio runs composition on the proposed capabilities with the current list of federated services and their capabilities, making sure that the composition is successful. That composed schema is then compared against the most recently registered schema to confirm that those changes are safe. If composition fails, then validation ends and results are returned to the user. Note that running
apollo service:check never updates the graph.
There are two types of failures that can occur during validation: failed usage checks and failed composition. Failed usage checks are failures due to breaking changes, like removing a field that an active client is querying. Failed composition, on the other hand, is a failure due to inability to compose the graph, like missing a
@key for an extended entity.
In general, an
apollo service:push should only be run after an
apollo service:check has passed, but even so, due to changes in other services, it's possible that the
apollo service:push command will encounter composition errors. When this happens, the federated service will still be updated as long as its capabilities are spec-compliant, but the graph will not be updated. This means that a new schema will not be associated, nor will the gateway's configuration be updated.
An example output of this behavior looks like this:
~$ apollo service:push --serviceName="launches" \ --serviceURL="http://launches-graphql.svc.cluster.local:4001/" \ --endpoint="http://localhost:4001/" ✔ Loading Apollo Project ✔ Loading Apollo Project ✔ Uploading service to Apollo The 'launches' service for the 'space-explorer@current' graph was updated *THE SERVICE UPDATE RESULTED IN COMPOSITION ERRORS.* Composition errors must be resolved before the graph's schema or corresponding gateway can be updated. For more information, see https://www.apollographql.com/docs/apollo-server/federation/errors/ Error [launches] Mutation.createLaunch -> requires the field `launch` to be marked as @external. The gateway for the 'space-explorer@current' graph was NOT updated with a new schema
The reasoning behind this functionality is that the service registry should always be the source of truth for what is running in your infrastructure. Even if that means that composition is failing in your infrastructure, the service registry should reflect that. However, you still want your gateway to function as it has been before the service deployment. Additionally, this functionality can be used to make dependent changes, like smoothly migrating a field from one service to another or introducing a circular service dependency.