Federation quickstart

In Part 1 and Part 2, we used Apollo-hosted services for our subgraphs. Now, let's see what we can do with our own subgraphs.

A service that you want to act as a subgraph can use any GraphQL server that supports Apollo Federation. This includes Apollo Server, along with the servers listed in Supported libraries.

1. Configure Apollo Server

If you're using a GraphQL server besides Apollo Server, consult its documentation to learn how to configure it for use as a federated service.

If you have an existing GraphQL API that uses Apollo Server, you can use that server as a subgraph with the @apollo/subgraph library. You can get started with this example server (which is not yet federated).

First, install the @apollo/subgraph library in your project:

1npm install @apollo/subgraph

Next, import the buildSubgraphSchema function in the file where you initialize ApolloServer:

1const { buildSubgraphSchema } = require('@apollo/subgraph');

Finally, modify your ApolloServer constructor by passing it a schema option instead of typeDefs and resolvers, like so:

1const server = new ApolloServer({
2  schema: buildSubgraphSchema({ typeDefs, resolvers })
3});

(As shown, you now pass your typeDefs and resolvers to buildSubgraphSchema.)

And that's it! You can now perform all of the same subgraph setup on your own service (introspection, schema registration, etc.) that you did with the Apollo-hosted services we used in the first two parts. Refer to those parts for guidance.

2. Learn about federated entities

In a federated graph, each subgraph's schema can refer to types and fields in another subgraph's schema.

Consider the Product type in our composed supergraph schema from Part 1. This type includes the following fields:

1type Product {
2  id: ID! @join__field(graph: PRODUCTS)
3  title: String @join__field(graph: PRODUCTS)
4  # ...more fields...
5  reviews: [Review] @join__field(graph: REVIEWS)
6}

As the federation-specific @join__field directive suggests, these three fields of the same type are defined across two different subgraphs!

This is possible because our products subgraph schema defines the Product object type as an entity. Entities are objects that other subgraphs can extend with additional fields.

It makes logical sense that the reviews field of a Product should be resolved by the reviews subgraph instead of the products subgraph. This reflects the design principle of separation of concerns.

Learn how to define and extend entities.

3. Try out schema checks

After you've registered your first subgraph schema, you can try out one of Apollo Studio's most powerful features: schema checks.

Schema checks are a paid feature of Apollo Studio. You can try them out with a free trial of a Team plan.

With schema checks, you can check whether some changes you want to make to your schema will affect any of the clients that use your graph. This feature is at its most powerful in your CI/CD environment, where you can automatically detect breaking schema changes before they're deployed to production.

1. Learn about the basics of schema checks

2. Learn about using schema checks with Apollo Federation

3. Learn how to use Rover in a CI/CD environment

Congratulations, you've completed the federation quickstart! If you have any feedback or suggestions for this tutorial, please click Rate article on the right.