Intro to Federation

1. Intro to Federation

Overview

Welcome to Voyage, a 3-part Odyssey series all about building a supergraph 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 supergraph 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.

Course	Content	Project
Voyage I: Federation from Day One (📍 You are here!)	What is Apollo Federation? How does it work? How can it help you modularize your graph and scale faster?	Create a supergraph for a new greenfield app called FlyBy
Voyage II: Federating the Monolith	How does Apollo Federation solve your current backend problems? How do you convert an existing, non-federated graph into a federated supergraph?	Convert the existing monolithic graph for an app called Airlock into a supergraph
Voyage III: Federation in Production	How do you maximize the power of Apollo Federation? How do you manage a supergraph in a production environment?	Expand on the Airlock app from Voyage II to add features like schema checks and data observation

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 supergraph architecture. Along the way, we'll put these concepts into practice by building a supergraph 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 operations to a single endpoint, and the supergraph will handle the rest!

Life before Apollo Federation

Before we jump into the details of how to build a supergraph, 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 fields for your entire graph are represented by a single schema 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 operation to the server. Then the server uses its schema, resolvers, and data sources to resolve the requested fields, 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 schema grows? As more types and fields get added to that one schema 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 supergraph are here to fix.

Note: You might hear the terms "supergraph" 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 supergraph. A supergraph has two key pieces:

One or more subgraphs
A router

Subgraphs

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

The example below shows that we could split the schema into two pieces: one piece for fields related to products data (name, numberInStock, price) and another piece for fields 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 schema is owned by a separate subgraph. A subgraph is a standalone GraphQL server with its own schema file, resolvers, and data sources.

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 schema around your microservice architecture.

The router

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

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

The supergraph schema is a bit like a map, helping the router determine which subgraph can resolve each field in an operation.

Why use Apollo Federation?

With a supergraph architecture, nothing changes from the client perspective. They still communicate with a single GraphQL endpoint (the router), 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 schema 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.

Practice

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?

Clients can query individual subgraphs directly as needed.Flexibility in subgraph configuration, which means subgraphs can have different numbers of instances, security protocols, or caching strategies.A smoother developer experience among teams, because there are clearer boundaries of responsibility for different parts of the graph.Since subgraphs can be developed independently, all cross-team communication can cease permanently.

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.

Share your questions and comments about this lesson

Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.