1. Intro to Federation


Welcome to Voyage, a 3-part Odyssey series all about building a with Apollo Federation!

Apollo Federation is an architecture for creating modular graphs. That means that your graph is built in smaller pieces that all work together. When your graph is built using this architecture, it's called a supergraph. The improves the developer experience for teams, making it easier to scale your product.

Check your plan: Part of this course covers the self-hosted router, which requires a GraphOS Enterprise plan. You can still follow along if your organization is on a different plan, but you won’t be able to complete certain hands-on tasks. You can also test out this functionality by signing up for a free Enterprise trial.

In this first course, we'll dip our toes into the world of Federation. We'll explore what Apollo Federation is, why it's useful, and the key pieces of a architecture. Along the way, we'll put these concepts into practice by building a for a travel-review app called FlyBy.

Ready? Let's get started! In this lesson, we will:

  • Specify how a supergraph differs from a non-federated graph
  • Identify the key pieces of a supergraph architecture
  • Explain the benefits of using a modular supergraph

Note: This series is intended for backend developers.

If you only work on the frontend, the good news is that your workflow stays the same, regardless of whether or not the backend uses Federation. You'll still send all your GraphQL s to a single endpoint, and the will handle the rest!

Life before Apollo Federation

Before we jump into the details of how to build a , let's take a step back and look at what life was like without Apollo Federation.

In a non-federated architecture, all the types and s for your entire graph are represented by a single file on a GraphQL server.

An example schema for a non-federated graph. All types and fields are defined in a single file called 'schema.graphql'.

When a client needs some data, it sends a GraphQL to the server. Then the server uses its , s, and s to resolve the requested s, package all the data together, and send it back to the client.

A GraphQL server receives requests from clients and resolves them

This works fine for smaller projects or teams, but what happens as your grows? As more types and s get added to that one file, it becomes harder to manage. Backend teams may face more frequent merge conflicts and slower development time.

But don't worry! That's what Apollo Federation and the are here to fix.

Note: You might hear the terms "" and "federated graph" used interchangeably. They mean the same thing: your graph's functionality is divided across smaller, modular graphs.

The structure of a supergraph

Let's take a closer look at the structure of a . A has two key pieces:

  • One or more subgraphs
  • A router


In a , your is built in smaller parts. The division of these parts is usually based on domain or on which team manages that part of the .

The example below shows that we could split the into two pieces: one piece for s related to products data (name, numberInStock, price) and another piece for s related to events data (date, attendees, venue).

The same example schema from earlier, but with the type definitions split across two schema files: products.graphql and events.graphql.

Each part of the is owned by a separate subgraph. A subgraph is a standalone GraphQL server with its own file, s, and s.

An illustration of two subgraphs, with each subgraph having its own schema file, resolvers and data sources.

Note: If you've worked with a microservice architecture before, this might look familiar. You can think of subgraphs as a way to orient the design of your graph's around your microservice architecture.

The router

A architecture also includes the router, which sits between clients and the subgraphs. The is responsible for accepting incoming s from clients and splitting them into smaller s that can each be resolved by a single subgraph.

The journey of a GraphQL operation, in a supergraph with the router and subgraphs

The does this work with the help of the supergraph schema. The is composed of all the s and types from each subgraph . (Later in the course, we'll dive deeper into composition and how the resolves client requests.)

The is a bit like a map, helping the determine which subgraph can resolve each in an .

Why use Apollo Federation?

With a architecture, nothing changes from the client perspective. They still communicate with a single GraphQL endpoint (the ), and they don't need to know a thing about how the graph is built under the hood.

The real benefits are on the backend. These benefits come from one of the core principles of Apollo Federation: the separation of concerns.

By splitting up our into subgraphs, backend teams can work on their own subgraphs independently, without impacting developers working on other subgraphs. And since each subgraph is a separate server, teams have the flexibility to choose the language, infrastructure, and policies that work best for them.

Three separate subgraphs, each with its own schema file. Developers can build, test, and deploy each subgraph separately.


Note: At the end of each lesson, you'll find a Practice section, which gives you a chance to check your understanding of new concepts.

Which of the following are benefits of using Apollo Federation?

Up next

The best way to see all of this for ourselves is to jump in and get building.

In the next lesson, we'll switch gears and get into the demo app for this course: our sweet travel-review platform called FlyBy.