Docs
Launch GraphOS Studio
You're viewing documentation for a previous version of this software. Switch to the latest stable version.

Federation quickstart

Part 3 - Working with subgraphs


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

A service that you want to act as a can use any that supports . This includes , 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 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:

npm install @apollo/subgraph

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

index.js
const { buildSubgraphSchema } = require('@apollo/subgraph');

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

index.js
const server = new ApolloServer({
schema: buildSubgraphSchema({ typeDefs, resolvers })
});

(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 (, 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 , each subgraph's schema can refer to types and in another subgraph's schema.

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

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

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

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

It makes logical sense that the reviews 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.

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

With , 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.

Previous
Part 2 - Composition in Apollo Studio
Next
Subgraphs
Edit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc.

Privacy Policy

Company