Why Apollo?

Simplify API sprawl with graph-based orchestration


Modern applications are a complex web of microservices, SaaS platforms, and internal systems—each with its own APIs. The API sprawl creates a fundamental orchestration challenge that developers face daily. Learn how Apollo's graph-based approach solves this problem more scalably than Backend for Frontends (BFFs) and goes beyond API management solutions.

The API orchestration challenge

Consider a typical e-commerce page that displays order status and estimated delivery date. To render this page, your application must orchestrate calls across several APIs.


API endpoint flow diagram showing hierarchical relationships between endpoints. Starting with USERS/:ID (GET CUSTOMER INFORMATION) at the top, which branches to two endpoints: LOYALTY/:USERID (GET LOYALTY ENTITLEMENTS) on the left and USERS/:ID/PRODUCTS (GET ORDER DETAILS) on the right. The right branch continues to INVENTORY/:PRODUCTID (GET INVENTORY). Both the left branch from LOYALTY and the bottom branch from INVENTORY converge at SHIPPING//:PRODUCTID (GET DELIVERY ESTIMATES) at the bottom of the diagram. Arrows indicate the data flow direction between these connected endpoints.

Developers must make sure calls happen in the right order. They also need to:

  • Execute some calls in parallel for performance

  • Convert between synchronous and asynchronous requests

  • Handle errors across multiple services

  • Transform data between different formats

  • Manage authentication and other security requirements across services

This traditionally requires writing procedural code for every API—a process that doesn't scale well as APIs multiply and evolve.

Apollo's approach

Graph-based API orchestration

Our key insight at Apollo is that you should view your APIs as a graph of objects rather than a collection of endpoints.

An entity relationship diagram showing an e-commerce database schema with four connected entities. The User entity has fields: id, email, active cart, billing address, and shipping address. It connects to both a Cart entity and a Shipping entity. The Cart entity contains: id, status, customer, products, and shipping fields, and connects to an Inventory entity. The Inventory entity has product and quantity fields. The Shipping entity contains id, customer, and status fields. Lines indicate relationships between these entities, forming a complete order management system.

With Apollo's approach, you model your organization's data at the API layer rather than the database layer. Specifically, you model your data in a GraphQL schema instead of writing procedural code.

Based on your schema, the Apollo Router handles the requests. It manages the execution plan, composes data from your APIs, and lets you declaratively configure security requirements, caching, and more at the graph level.


A system architecture diagram showing Apollo Router as the central component. On the left side, there are Clients (represented by small icons). Apollo Router connects to three API services within a Graph: Products API, Users API, and Inventory API.

Apollo Connectors enhance this approach by providing a declarative way to incorporate REST APIs directly into your graph, eliminating the need for custom integration code while maintaining the benefits of graph-based orchestration.

How it works

A graph isn't a replacement for your existing APIs! Instead, it's a way to connect them and make them more accessible and useful for every client that interacts with your data. While you don't need to know GraphQL to get started with Apollo, we use GraphQL as our schema language because it's powerful and intuitive.

  1. Schema definition: You model your data and relationships at the API layer in GraphQL.

  2. Declarative requests: Clients describe the data they want and not how to get it.

  3. Automatic orchestration: The router creates a plan to efficiently divide a request into separate API calls. It then executes the plan and combines all the fetched data into one response it returns to the client.

The benefits of this approach multiply once you're trying to orchestrate APIs across more than one service.

Core pillars

These pillars are often applied to building individual pieces of software. Apollo's graph-based approach extends them to address orchestration across software.

Open source and standards-based

Building software publicly in the open creates trust. Beyond our industry-standard open source SDKs, Apollo is a key member of the GraphQL Foundation—a standards body under the Linux Foundation.

By contributing to community discussions and specifications, we ensure our orchestration technology is transparent, trustworthy, and shaped by diverse industry perspectives. This standards-based approach creates not just trust, but more secure and reliable software that benefits the entire ecosystem.

Developer experience

Apollo leverages GraphQL's type safety to give developers instant feedback in their IDE and throughout the development process, identifying issues as early as possible.

Apollo's toolkit includes:

  • Language-specific tooling: Apollo Language Server powers extensions for VS Code and JetBrains IDEs that provide syntax highlighting, validation, and autocompletion.

  • Apollo Sandbox: An in-browser IDE for exploring and testing your graph with real-time schema validation and query execution.

  • Build-time validation: Incorporating schema checks into your CI/CD automatically catches errors before deploying to production.

  • GraphOS Studio: A collaborative platform for teams to explore schemas, monitor performance, and track changes across your graph.

Composable building blocks

Apollo treats your APIs as modular, reusable components. Apollo Federation lets service owners declare their capabilities to a registry via GraphQL schemas, allowing the system to automatically compose them into a unified graph.

This composable architecture means teams can independently publish services without complex coordination, while clients can access the entire API surface.

Declarative architecture

GraphQL lets you declare what data you need, not how to retrieve it. Apollo's products build on this principle to simplify API orchestration:

  • Apollo Federation fulfills the promise of GraphQL by letting you declare the data you need, regardless of the underlying service(s) required for that data.

  • Apollo Connectors take this a step further by enabling you to declaratively integrate REST APIs into your graph via schema directives.

  • The Apollo Router's query planner automatically determines the optimal execution path—making parallel calls when possible, handling dependencies, and efficiently coordinating across services.

By adopting a declarative approach at every level, you remove the need for manual orchestration code, reducing complexity and maintenance.

What Apollo customers say

Apollo helps API-rich companies get the most out of their API investments and ship great products more quickly. Here's what some of our customers have to say:

Cox Automotive: Development velocity and savings

We can compose [...] services in ways we never could before. And considering the process would have typically required months or even a year of work from multiple engineers, Apollo Connectors saved us millions.

- Mark Meiller, Principal Engineer of Data Services

Read story

RS Components: 67% faster performance

When we introduced more efficient, event-driven architecture through Apollo Federation, [it] not only reduced the load on our infrastructure but also sped up our website's response time.

- Juan Carlos, Senior Software Engineer

Read story

Netflix: Data discoverability

[Numerous times] people ask, 'What does this subgraph do?' And now we can simply go in and see it all, what it does, who calls it. That sounds basic, but we lacked this information with previous APIs.

- Bruce Wang, Director of Product Platform Systems

Read story

Getting started

Apollo is free to get started, with plans that scale to meet your needs. Follow our guides to set up your first graph.

Feedback

Ask Community