Introduction to Apollo Federation

What is Apollo Federation?

Apollo Federation lets you declaratively combine multiple GraphQL APIs into a single, federated graph. This federated graph enables clients to interact with multiple APIs through a single request.

A client makes a request to the single entry point of the federated graph called the router. The router intelligently orchestrates and distributes the request across your APIs and returns a unified response. For a client, the request and response cycle of querying the router looks the same as querying any GraphQL server.

Benefits of federation

Microservices architecture

Apollo Federation lets API teams operate in a microservices architecture while exposing a unified GraphQL API to clients. Understanding these concepts can help you get the most out of federation.

Preserve client simplicity and performance

A client may need to make multiple requests when interacting with multiple non-federated GraphQL APIs. This can happen when an organization adopting GraphQL has multiple teams developing APIs independently. Each team sets up a GraphQL API that provides the data used by that team. For example, a travel app may have separate GraphQL APIs for users, flights, and hotels:

With a single federated graph, you preserve a powerful advantage of GraphQL over traditional REST APIs: the ability to fetch all the data you need in a single request.

The router intelligently calls all the APIs it needs to complete requests rather than simply forwarding them. For performance and security reasons, clients should only query the router, and only the router should query the constituent APIs. No client-side configuration is required.

Design schemas at scale

Some alternative approaches to combining GraphQL APIs impose limits on your schema, like adding namespaces or representing relationships with IDs instead of types. With these approaches, your individual GraphQL API schemas may look unchanged—but the resulting federated schema that clients interact with is more complex. Subsequently, it requires you to make frontend as well as backend changes.

With Apollo Federation, clients can interact with the federated schema as if it were a monolith. Consumers of your API shouldn't know or care that it's implemented as microservices.

Maintain a single API

With federation, every team contributes directly to the overall federated GraphQL schema. Each team can work independently without needing to maintain multiple API layers. This frees your platform team to focus on the quality of your API rather than keeping it up to date.

Next steps

Before continuing, it's helpful to know some terminology:

• When combining multiple GraphQL APIs, the single, federated graph is called a supergraph.
• In a supergraph, the individual GraphQL APIs are called subgraphs.

Different subgraphs in the same supergraph can use different server implementations and even different programming languages as long as they are federation-compatible.

Additional resources

Depending on your goals, you have several options for learning more about federation:

• If you're new to federated architecture, this overview article can familiarize the concepts.

• If you'd like to recap the key concepts of Apollo Federation, the video below gives a great overview.

  Watch the video overview

• If you learn best by doing, this interactive course teaches you to build an example supergraph using Apollo Federation.

Further documentation

Once you're ready to apply federation to your own APIs, these docs sections can help you get started:

• Conceptual overview of Federated Schemas
• Guide on using Apollo GraphOS to automate and manage deployments of your federated schemas (this is also known as Managed Federation)
• Reference materials for:
  • Performance considerations
  • Debugging and metrics
  • Subgraph specifications for federation-compatibility