Docs
Launch GraphOS Studio

Introduction to Apollo Federation

Learn how to combine your GraphQL APIs into a unified supergraph


What is Apollo Federation?

lets you declaratively combine multiple 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 called the router. The intelligently orchestrates and distributes the request across your APIs and returns a unified response. For a client, the request and response cycle of the router looks the same as querying any .

Clients
Router
GraphQL API
A
GraphQL API
B
GraphQL API
C

Benefits of federation

Microservices architecture

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

đŸ’¡ TIP

Preserve client simplicity and performance

A client may need to make multiple requests when interacting with multiple non-federated 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:

Hotel
data
Hotels API
Flight
data
Flights API
User
data
Users API
Clients

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

Router
Users API
Flights API
Hotels API
Users
data
Flights
data
Hotels
data
Clients

The intelligently calls all the APIs it needs to complete requests rather than simply forwarding them. For performance and security reasons, clients should only 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 APIs impose limits on your schema, like adding namespaces or representing relationships with IDs instead of types. With these approaches, your individual GraphQL 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 , 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 . 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 APIs, the single, federated graph is called a supergraph.
  • In a , the individual APIs are called subgraphs.

Supergraph
Subgraph
A
Subgraph
B
Subgraph
C
Router
Clients

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

đŸ’¡ TIP

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 , the video below gives a great overview.

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

Further documentation

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

Best practices

Whether your implementation is already underway or just starting, you can use the Supergraph Architecture Framework (SAF) to learn about best practices. The SAF includes an assessment to quantify your 's current state and identify areas for improvement.

Next
Project setup
Edit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc.

Privacy Policy

Company