Creating a Demand-Driven 


API Strategy
Learn how technical leaders are unblocking agility
across teams with a central yet modular GraphQL
API layer called a supergraph.
EXECUTIVE In the past twenty years, advances in distributed systems and service-oriented
SUMMARY architecture patterns have led to an explosion of APIs. While services teams
now move quickly and autonomously, their rapid production only adds to an
ever-expanding sprawl of REST APIs that consuming clients must integrate
and orchestrate, slowing delivery and entangling teams. Attempts to build
REST-based backend-for-frontends (BFFs) for each use case proved
unscalable, only adding to API sprawl and slowing velocity again.

This whitepaper outlines how technology leaders unlock agility across teams
by serving the needs of API consumers with a central yet modular GraphQL API
layer called a supergraph. You will learn how:

GraphQL enables faster application development and solves

performance issues across client-server architectures.

A new federated GraphQL architecture called a supergraph enables

organizations to support GraphQL at a larger scale.

Apollo GraphOS operationalizes a supergraph across an organization. It

provides more efficient developer workflows, a secure source of truth,
and improved performance at scale.
EVOLUTION AND SCALE ACROSS THE STACK

During the modern era, software teams shifted to service oriented architectures to meet one goal --
releasing better features in less time. Decoupling software architecture enables teams to ship early,
ship often, build new interfaces to reach new audiences, and pick the right tool or language for the
job. And this strategy by and large has worked. Organizations that were happy to ship a change to the
website 20 years ago now live in an omni-channel world. Their core products span web, Android, iOS,
and external API-driven partners.

Over this period, every layer of the stack and way of work has evolved rapidly.

Monolithic era Service oriented era

One UX → Multiple UXs

One or two languages → Many languages

One database → Many databases

One data center → Multi-cloud, including cloud services

Synchronized workflows → Asynchronous workflows

Tightly coupled teams → Loosely coupled teams

Point-to-Point APIs Fail to Scale

Distributed systems introduce a barrage of complexity to the API layer. By their very nature, REST and
other point-to-point API architectures tend to be focused on surfacing and providing raw data without
considering how that data will be consumed. As more clients are introduced, this data-centric
approach introduces complexity as the API surface area grows without bound. Services teams often
end up writing and maintaining backends-for-frontends (BFFs) that are tailored to the needs of each
client and abstract API complexity for client teams. Whether services teams have to write multiple
BFFs to handle data fetching and define business logic or these responsibilities fall to the client teams
themselves, the extra work slows software teams down in the following ways:

Creating a Demand-Driven API Strategy 03

 The tightly coupled nature of this approach introduces the risk of breaking changes.
BFFs add opportunity costs, as these efforts contribute no direct business value and must be
updated and maintained over time.
As new interfaces are introduced, these challenges are only compounded.

Equipping Services Teams with a Faster Way to Deliver Value

Services teams need better tools and workflows to accommodate the needs of a dynamic, distributed
stack. It shouldn’t be a herculean effort to accommodate changes between backend and clients, or
abstract service complexity with backend-for-frontends (BFFs). They should be empowered to use the
same agile workflows that client and DevOps teams have. And client developers shouldn’t think
about API orchestration or integrations at all – they should think about building and iterating
features. Modern development teams are delivering on this vision not with more backend-for-
frontends, but with a new declarative API layer of the stack – a central but modular GraphQL API layer
called a supergraph.

Point-to-point API limit innovation

When client teams build applications that fetch data directly from REST APIs through a point-to-point
connection, the following issues slow down development across an organization:

No single source When clients must consume and orchestrate across multiple REST interfaces, they
of truth encounter multiple sources of the same data. Determining the “right” one takes
time, but failing to do so leads to inconsistent customer experiences. What to do?

Decreased REST API endpoints are fixed and versioned. Exposing new functionality means
developer 
 making changes to the client. Since it’s not always clear which teams manage which
productivity APIs, this leads to high coordination cost and team-to-team coupling.

P erformance When clients have to make multiple sequential network calls across multiple
issues services, it introduces extra latency. This is particularly painful for mobile apps on
slower connections. The cost of maintaining a separate endpoint with exactly the
right data for each component becomes untenable as the needs of clients change.

Creating a Demand-Driven API Strategy 04

GraphQL brings composability to APIs

Modern engineering teams are now codifying other parts of the stack to
REST was
empower decoupled teams to seamlessly ship updates. Technologies like
conceived to serve
AWS CloudFormation and HashiCorp Terraform enable DevOps teams to
one interface: the
define parts of infrastructure as modules. Policy-as-Code tools like OPA and
browser. It is a
Snyk enable teams to integrate security and compliance policies into a CI/
tried and true
CD pipeline. These tools often provide declarative languages that provide
means to deliver a
the same composability that feature developers have. Codifying best
single service. It
practices into various parts of a stack streamlines redundant work. It also
was not built to be
leads to improved asynchronous collaboration, consistent releases with
a complete service
less code review, and better visibility for an entire technical organization.
layer for a
distributed stack.

A Graph as the Source of Truth

This composability is critical at the API layer as well. Companies like Facebook and Netflix have
triggered a sea change in the industry by switching to GraphQL. GraphQL was created by Facebook to
allow their apps to fetch data from an explosion of microservices more efficiently. It creates an API
abstraction layer, freeing developers from the data-fetching code that slows application performance
and contributes no value to a business.

Every service
added to a graph is
easily accessed by
any number of
clients from a
single endpoint.

Creating a Demand-Driven API Strategy 05

It starts with a source of truth – the schema. All of the data that defines a business domain is codified
in a centralized GraphQL schema on a server. This acts as a “menu” of all of the data available to
clients and describes the data’s shape. Service developers define types as well as how they relate to
one another. GraphQL resolvers connect GraphQL fields, graph edges, queries, mutations, and
subscriptions to their respective data sources and microservices.

With GraphQL, service teams define APIs not in terms of their data models, but with entities and
relationships required by client applications. Once GraphQL developers understand what data client
teams need, they can structure the schema as intuitively as possible. Developers then no longer have
to spend significant hours writing data fetching code.

Client teams use a query language to describe the data they need, 

and only have to query a single endpoint.

Client

Query

getAuthor getPostsByTi
tle

posts

Author Post

author

Adopting a Client-Centric Approach

GraphQL enables service teams to build a much more self-service experience, as it enables client
developers to better comprehend what data lives in the backend. This approach starts by treating a
GraphQL API as a “contract” between client teams (the consumers) and services teams (the
producers). Once GraphQL developers better understand the needs of client teams, they can model
the schema in a way that enables these teams to operate more independently.

Creating a Demand-Driven API Strategy 06

GraphQL solves many of the problems that technology leaders face when attempting to scale clients:

A single source of Service teams use a declarative Schema Definition Language (SDL) to define a
truth for a single business domain in a single graph, which can then be used to support any
business domain number of clients. By decoupling the frontend and backend, it becomes easier to
roll out changes across numerous clients.

Increased developer GraphQL’s language enables client developers to declaratively write queries and
productivity predict the shape of the data they will return. A self-service approach eliminates
the need to mitigate the complexities of REST endpoints.

Improved 
 Due to its hierarchical nature, a GraphQL query obtains all of the data it needs
performance across multiple data sources in one request. An equivalent REST service could
require multiple round-trips which is resource-intensive and particularly slow on
mobile connections.

GraphQL often takes off in an organization because it unblocks multiple teams to ship changes at a
more rapid pace. Its benefits grow as more clients and services are added, which encourages
iteration, prevents technical debt, and future-proofs the business.

GraphQL as a lingua franca across REST, gRPC, or even SQL

The internet is rife with “GraphQL vs REST debates,” and you will see no shortage of opinions on the
matter. It’s not an either/or scenario for companies sold on GraphQL. The GraphQL SDL can define
disparate concepts from data that lives across a variety of services, including REST APIs. Organizations
with legacy REST APIs do not have to rewrite them to take advantage of GraphQL’s performance or
productivity benefits. GraphQL servers can actually simplify data fetching from REST APIs and help
handle caching, request deduplication, and errors while resolving operations. To a GraphQL client, it’s
all the same. The query payload contains a simple and streamlined typed JSON blob.

In this respect, GraphQL isn’t just a means to create an API. It provides service teams with a declarative
language to define an organization’s data and services together as graphs. By using GraphQL as a
lingua franca, service teams can define consistent definitions for these domains across two or 2,000
clients. This eliminates the need to abstract REST APIs with multiple backends-for-frontends or
rewrite them as business requirements change.

Creating a Demand-Driven API Strategy 07

the supergraph: A graph of graphs

As teams discover the benefits of GraphQL, its use spreads across the organization. Yet without
planning, one of two undesirable anti-patterns occur:

A GraphQL Monolith: As the graph delivers value, it naturally grows to include new domains. The
result is a single monolithic schema. While simplifying the developer experience for client teams,
each schema change becomes harder and harder to review and approve. The owners and
reviewers of the monolith quickly become a bottleneck.

Fractured GraphQL APIs: Seeking to avoid the perils of a monolith, some teams chose to define
their own graphs. This inevitability leads to duplication of functionality and infrastructure across
teams and APIs.

In search of an architecture that avoided these pitfalls, Apollo partnered with Netflix in 2019 to create
a source-available GraphQL architecture called Apollo Federation. This approach presents a third and
more sustainable way to manage GraphQL at scale. With Federation, teams practice decoupled
collaboration, meaning:

Separate service teams maintain their own GraphQL APIs

Architects define core entities that exist across these GraphQL APIs in a graph of graphs
Client developers consume data from this federated graph

Federation provides the simplicity of the monolith for client teams, but the modularity of a more
decoupled approach for service teams. In a federated graph, individual GraphQL APIs are maintained
by separate teams on separate servers and can be written in any language. Defined as individual
subgraphs, they sit behind a single API router and access point. A process called composition takes all
subgraph schemas and intelligently combines them into one schema, ensuring a consistent and
performant runtime. This defines a supergraph architecture, and it enables service teams to support
more clients with greater consistency and less redundant work.

Creating a Demand-Driven API Strategy 08

 Application The Graph Microservices

graph router
product info user

pricing share

favorites reviews

inventory cart

“It’s in the graph”

Federation doesn’t just abstract API details from client developers. Like a single GraphQL API, it is a
“contract” that ultimately best serves the needs of clients. At the core of Apollo Federation is a
federated schema. It provides a composition layer for architects to define business domains using
object types that live across different GraphQL APIs. Architects define core entities and express the
relationships between these different entities via declarative federation semantics. The resulting
schema is a single source of truth for multiple business domains across an entire organization.

A well-architected supergraph provides a great developer experience to client developers who build
new features against the existing graph. It should be treated like any other product within a technical
organization. Subgraph owners should respond to changing requirements by iteratively expanding the
graph. Client can then receive timely notifications of newly available fields. This defines a demand-
centric approach to API strategy, rather than a service-centric approach. It enables technical teams to
be more agile to meet the needs of the business.

Creating a Demand-Driven API Strategy 09

A supergraph shouldn’t feel like another hop in the stack when it’s time to start processing queries. The
Apollo Router provides a next-generation runtime environment built specifically for supergraphs. The
Apollo Router was written in Rust for improved performance and low variance. It accepts client
requests, plans and executes those requests across subgraphs, and returns responses back to the
client. Benchmarks in high-traffic production environments show less than 10 milliseconds of latency
during this process. 

A supergraph enables technology leaders to better support their teams as they expand their GraphQL
usage across an organization:

A single source of By leveraging one graph, client developers access a myriad of data and services
truth for many from a single query. There is one central catalog of all available data for services
business domains written in over 12 languages and frameworks.

Increased Each team develops their subgraph independently and operates it on their own
developer 
 release cycle. Implementation cost is minimized because graph implementation
productivity work isn’t duplicated. Code, queries, skills, and experiences are then portable
across teams.
across API teams

Improved 
 By processing requests through Apollo Router, API teams gain the composability
performance benefits of a supergraph without significant latency.

At scale, this approach offers the best of both worlds for all teams:

Client teams

Architects and Service teams

Backend teams

Can still use a single endpoint to fetch Can share code across a central Ensure that work is left untouched and
data, but don’t have to coordinate with schema and infrastructure. They can continue to be accessed via existing
multiple GraphQL API teams to get the collaborate yet still work APIs, such as REST, SOAP, gRPC, Thrift,
data they need for their apps. asynchronously on their part of the or even SQL.
graph.

Creating a Demand-Driven API Strategy 10

GraphOS operationalizes a supergraph

With a centralized source of truth for GraphQL APIs, technical leaders are free to standardize security,
infrastructure, and workflows across an organization. Apollo offers GraphOS, a platform that enables
teams to better standardize workflows and collaborate on a supergraph. It acts as a central hub of the
system, powering developer tools, workflows, or any business processes that would benefit from
awareness of the graph and any actual or proposed changes to it. It also provides a centralized data
plane to extend Apollo Router, enabling organizations to accommodate their API security, scalability,
and extensibility needs. GraphOS customers can perform most of their customizations in YAML, but can
also use Rhai scripting or the language of their choice.

GraphOS is available both as a hybrid-prem offering that comes with enterprise support and SLAs
(Enterprise) and a SaaS offering (Serverless). It was built with feedback from Apollo customers such as
PayPal, Walmart, and Expedia.

Conclusion

GraphQL is a critical tool for removing technical difficulties and organizational friction that arise across
a distributed architecture. As an organization introduces new interfaces, data sources, and capabilities,
a supergraph enables API teams to roll them out in less time for more people as the business requires.
It’s a competitive advantage that companies can use to expand and improve their digital footprint and
offerings in the modern world.

Creating a Demand-Driven API Strategy 11

More resources

Pre-production 
 Apollo Odyssey Associate Certification

with GraphQL Adapting a GraphQL Mindset When Migrating from REST

Principled GraphQL

Introduction to Apollo Federation

Scaling GraphQL Apollo Odyssey Professional Certification

Building a Distributed Data Graph with Apollo Federation

Best Practices for Designing Federated GraphQL Schemas

Apollo GraphOS https://www.apollographql.com/

For more information on Apollo GraphOS, contact the Apollo sales team.

© 2023 Apollo Graph Inc. All rights reserved.

Creating a Demand-Driven API Strategy 12