These materials are © 2022 John Wiley & Sons, Inc.

Any dissemination, distribution, or unauthorized use is strictly prohibited.

 Choosing
a GraphQL
Architecture
Apollo Special Edition

by Brian Culp

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Choosing a GraphQL Architecture For Dummies®, Apollo
Special Edition

Published by
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
Copyright © 2022 by John Wiley & Sons, Inc.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without
the prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com,
Making Everything Easier, and related trade dress are trademarks or registered trademarks of
John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not
be used without written permission. Apollo Graph and the Apollo Graph logo are registered
trademarks of Apollo Graph. All other trademarks are the property of their respective owners.
John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: WHILE THE PUBLISHER AND AUTHORS HAVE

USED THEIR BEST EFFORTS IN PREPARING THIS WORK, THEY MAKE NO REPRESENTATIONS
OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF
THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES REPRESENTATIVES, WRITTEN SALES
MATERIALS OR PROMOTIONAL STATEMENTS FOR THIS WORK. THE FACT THAT AN ORGANIZATION,
WEBSITE, OR PRODUCT IS REFERRED TO IN THIS WORK AS A CITATION AND/OR POTENTIAL SOURCE
OF FURTHER INFORMATION DOES NOT MEAN THAT THE PUBLISHER AND AUTHORS ENDORSE
THE INFORMATION OR SERVICES THE ORGANIZATION, WEBSITE, OR PRODUCT MAY PROVIDE
OR RECOMMENDATIONS IT MAY MAKE. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT
THE PUBLISHER IS NOT ENGAGED IN RENDERING PROFESSIONAL SERVICES. THE ADVICE AND
STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR YOUR SITUATION. YOU SHOULD
CONSULT WITH A SPECIALIST WHERE APPROPRIATE. FURTHER, READERS SHOULD BE AWARE
THAT WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN
THIS WORK WAS WRITTEN AND WHEN IT IS READ. NEITHER THE PUBLISHER NOR AUTHORS
SHALL BE LIABLE FOR ANY LOSS OF PROFIT OR ANY OTHER COMMERCIAL DAMAGES, INCLUDING
BUT NOT LIMITED TO SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR OTHER DAMAGES.

For general information on our other products and services, or how to create a custom For
Dummies book for your business or organization, please contact our Business Development
Department in the U.S. at 877-409-4177, contact info@dummies.biz, or visit www.wiley.com/go/
custompub. For information about licensing the For Dummies brand for products or services,
contact BrandedRights&Licenses@Wiley.com.
ISBN: 978-1-119-89988-4 (pbk); ISBN: 978-1-119-89989-1 (ebk). Some blank pages in the print
version may not be included in the ePDF version.

Publisher’s Acknowledgments

Some of the people who helped bring this book to market include the following:
Project Manager: Carrie Acquisitions Editor: Ashley Coffey
Burchfield-Leighton Client Account Manager: Cynthia
Sr. Managing Editor: Rev Mengle Tweed
Managing Editor: Camille Graves

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Introduction
T hirty million GraphQL downloads on NPM (npmcharts.com)
can’t be wrong. And that’s 30 million per month, by the way.

Apollo GraphQL has been building industry-leading graph technol-

ogy since 2015. Over the years, Apollo leaders have had thousands
of conversations with the developers implementing GraphQL at
companies of all sizes. This short book is an attempt to pass along
a recommendation for the best way to build a GraphQL application
programming interface (API) at scale.

These discussions have led to one conclusion about the architec-

ture solution that works best for most enterprise consolidations:
the supergraph.

About This Book

This book lays the groundwork for understanding how an Apollo
supergraph architecture delivers value across the enterprise. The
topics discussed here should resonate with those in the following
roles:

» Software architects and engineering leads: If your

company is currently using GraphQL, you’ve likely faced
challenges related to managing a monolithic graph or
wrangling multiple smaller graphs.
Consolidating these graphs into a unified supergraph can
help reduce friction between teams, enhance developer
experience, and provide better observability of how data is
consumed.
» Product owners: Building your supergraph isn’t just about
architecture. It’s also about an organizational transformation
that delivers value to the customer faster.
The strategy presented in this book should illuminate a path
to realizing the full potential of your company’s data and
products.

Introduction 1

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 »» Developers and engineers: Whether you’re on a client team
building features utilizing your graph or actively maintaining
a GraphQL server, this book should provide a better
understanding of how your work aligns to a broader
GraphQL strategy.

Icons Used in This Book

This book uses the following icons to indicate special content:

You don’t want to forget this information. It’s essential to gain a

basic understanding of graph or graph architecture.

The Tip icon points out practical advice that saves you time and
effort when designing/consolidating your graph.

These icons help you avoid mistakes in GraphQL.

Beyond the Book

This book can help you discover more about choosing the right
GraphQL architecture, but if you want resources beyond what this
book offers, Apollo has some links for you:

»» Learn GraphQL and about Apollo with interactive tutorials.

Visit www.apollographql.com/tutorials.
»» Want to scale your supergraph company-wide? Visit
www.apollographql.com/contact-sales to speak with
product specialists.

2 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Finding solutions to problems with
GraphQL

»» Seeing who’s driving GraphQL adoption

Chapter  1
Understanding GraphQL

I
f you’re reading this sentence, you’re likely using or consider-
ing using GraphQL already, or at the very least you’re familiar
with some of the issues it solves — problems like underfetching
or overfetching.

In case you aren’t familiar with GraphQL.  It stands for Graph

Query Language, but don’t let that confuse you. It’s not some-
thing you use for calling up a database; instead, it’s an application
programming interface (API) technology designed to help make
fetching data much simpler.

Solving Problems with GraphQL

Software architects and developers (and now at least one book
author) know that GraphQL is an elegant solution to one of the
biggest challenges posed when using representational state
transfer (REST) API endpoints. With a REST API, you need to build
many different endpoints to build an application.

For example, if you’re a developer writing code for an app that

tracks the performance of soccer teams, you may use a REST API
endpoint to fetch a player, returning the player name, position,
and jersey number. You may need yet another endpoint, however,
to retrieve a player with the number of matches played and goals

CHAPTER 1 Understanding GraphQL 3

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 scored. What I describe here is the textbook underfetching prob-
lem of REST. One query doesn’t always fetch all the data you want.

Or, the API you use may retrieve all stats from all players. Your
job, then, would be to sift through the results of that massive
pile of soccer player information and display just the desired data:
something like the name and number of goals to date. This data
dump of too much information sums up the overfetching problem.

The solution? GraphQL, which allows software developers to write

queries by using a single API endpoint for just the data they want
from the server. With GraphQL, you write a query for a specific col-
lection of data, and this query mirrors results sent back from the
server in JavaScript Object Notation (JSON) format. To apply this to
the soccer app example, the developer could use GraphQL to create
a request for only the player’s name, number, and goals scored.

In sum? Every time, you’re calling the same endpoint to retrieve

only the data you need. Elegant. And because of that, GraphQL is
widely adopted.

One of the best parts of GraphQL is that it provides a clean defi-

nition of the data available in your API through a schema. The
schema describes the types and fields you can query and also
includes any relationships between those types. The schema is
what enables GraphQL to have such a variety of useful developer
tools, including auto-completing query explorers such as Apollo
Explorer, editor, and integrated development environment (IDE)
integrations, query validation tools, code generation, automatic
mocking, and more.

Driving GraphQL Adoption

GraphQL has become so popular because it’s the power of the sin-
gle, all-purpose API. Apollo GraphQL, then, is the platform that
makes all this single API magic possible. Apollo GraphQL is a plat-
form that helps teams build, manage, and scale a unified network
of data, services, and digital capabilities. Apollo and GraphQL are
often used and appear in sentences in close proximity, but they
aren’t the same thing.

To get the most out of your GraphQL stack, make sure you’re using
the recommended architecture. The rest of this book explores this
very topic.

4 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Managing suboptimal GraphQL
architectures

»» Looking at Graph QL architecture options

Chapter  2
Facing Common
GraphQL Architectures
Challenges

I
n this chapter, you look at the options available for engineers
and software architects planning a GraphQL implementation or
optimizing an existing one. As with any tool, if you don’t use it
in the way it was designed, chaos can ensue.

Dealing with Suboptimal GraphQL

Architectures
With insight into how your teams use GraphQL across the com-
pany, you can make better decisions about whether and how your
GraphQL efforts can be optimized. Your architecture choices play
a key role in that optimization effort. Understand the available
options to set up your success.

CHAPTER 2 Facing Common GraphQL Architectures Challenges 5

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Looking at GraphQL Architecture Options
Graphs are powerful tools for modeling many real-world phenom-
ena because they resemble our natural mental models and verbal
descriptions of the underlying business. Best practice, then, dic-
tates that you think of your business domain as a graph and then
define the schema accordingly. If it helps, think of your GraphQL
schema as a shared language for both your team and your users.

The effort to conceive of these schemas leads to discussions of

architecture. In many new implementations of GraphQL, the
result of the initial experimentation is to try and achieve the per-
fect graph. This perfect graph even has a name: the Monolith.

Monolith
Teams eager to reap the benefits of GraphQL’s client-centric
data-fetching capabilities charge ahead and implement a GraphQL
application programming interface (API) within the context of
their, and only their, use case. But other teams soon want to get
in on the act. The result is a heroic attempt at company after com-
pany setting about designing the one perfect schema — the one
schema that will serve all the companies needs for all time.

The monolith pattern can take on two forms. In its first form,
teams may share one codebase for a GraphQL server that’s used
by one or more clients. In some cases, client code may even live
in the same repository as the GraphQL server. No matter how the
code is organized, ownership of this graph is shared by the differ-
ent developers who contribute to the graph.

In its alternative form, a single team may own a GraphQL API

that’s accessed by multiple client teams. This team typically
defines a set of standards for the graph and champions its adop-
tion throughout the organization. But whatever form the monolith
takes, the net result is almost always the same: It doesn’t scale
because after you have multiple teams collaborating on the same
monolith, release schedules don’t align: One team’s changes break
others. Typically, the team responsible for the monolith becomes
the bottleneck, having to review every change to prevent outages.

Multiple GraphQL APIs (BFFs)

If one single schema doesn’t work, why not just build several? When
the single GraphQL monolithic schema becomes too unwieldy,

6 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 teams often solve the issue (or try to) by adding more schemas.
This becomes an architecture pattern known as Backend for
Frontend (BFF). You can learn more about BFFs at samnewman.io/
patterns/architectural/bff.

BFF patterns attempt to solve the problem of requiring different

clients (for example, web and iOS) to interact with a monolithic,
general-purpose API. Alternatively, BFFs can save client applica-
tions from making requests to multiple backend services to obtain
all data required to render a particular user interface view.

As a solution, BFFs add a new layer where each client has a ded-
icated BFF service that directly receives the client’s requests and
is tightly coupled to that user experience. For teams creating
BFF services, GraphQL can be a natural fit for building out this
intermediary.

So what’s the issue? Why not just stop there? Because BFFs also
don’t scale well. In fact, BFFs end up resembling the problem that
GraphQL is so good at solving. BFFs result in duplicated logic and
more surface area to maintain. Additionally, BFFs lead to capabil-
ity gaps between platforms.

Schema stitched graph

So if the monolith gives way to the BFF, which is essentially a
schema divided among several modules or microservices, each
managed independently, then the solution is obvious, right?
Smush all those schemas back together again. One could almost
describe that as stitching the schemas into a single graph.

As it happens, the schema stitched graph architecture was a

common practice among enterprise teams who develop their
own GraphQL schemas in parallel. Schema stitching is a way to
combine those multiple schemas into a single GraphQL gateway
schema. The stitched schema then delegates requests through
to underlying graph endpoints. In this way, the stitched graph
delivers much of the same benefits as a single graph schema. But
there’s a problem with schema stitched architectures, too.

Schema stitching requires a lot of work to write and maintain

the resolvers that combine subschemas. In addition, engineers
must build, deploy, and maintain the stitching code that brings
all these schemas together, which still results in a bottleneck and
more manual work. So how do you resolve that?

CHAPTER 2 Facing Common GraphQL Architectures Challenges 7

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 The supergraph
Apollo Federation was first announced in 2019 as a better
approach to monoliths, BFFs, and schema stitched graphs. With
Apollo Federation, you create a supergraph composed of sub-
graphs that can be maintained by independent backend teams.
The supergraph provides both a unified interface and modular
architecture for building your GraphQL API. Learn more about the
supergraph here: www.apollographql.com/supergraph.

These companies liked that Apollo Federation was published as an

open-source specification, that it included support for GraphQL
servers in a wide variety of languages, and that it allowed for ser-
vice extension without writing custom gateway code. By using
Apollo Federations, teams could define linkages between sub-
graphs using metadata called directives. These eliminate the need
for tedious stitching code and also make it much easier to build
tooling to verify the integrity of the supergraph.

Additional benefits of the supergraph include

» Improved performance and less code to maintain

» Improved collaboration across frontend and backend teams
• Backend teams can safely evolve their subgraphs
independently, knowing that their changes will be
automatically composed and validated.
• Frontend teams have a one-stop shop for accessing all of
their company’s capabilities without having to write
tedious boilerplate code.

FINDING EARLY SUCCESS

One early adopter of the supergraph was the travel website and app
developer Expedia. By running Apollo Federation against schema
stitching in an A/B test, Expedia quantified the benefit of moving to
Federation, a switch that bore immediate fruit.

For starters, the federated implementation improved gateway pro-

cessing, which in turn improved application performance (by as much
as 50 percent compute time). The company was also able to delete
many lines of gateway code, which simplified Expedia’s gateway
deployments.

8 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Looking GraphQL architecture attributes

»» Choosing the supergraph

Chapter  3
Choosing the Right
GraphQL Architecture

T
he architecture that you choose is whatever delivers the
most value for your company. That said, there’s a reason
this book exists, and one of those reasons is to convey the
notion that some architectures are better choices than others.

For large enterprises with multiple teams and multiple services,

the architecture of choice is the supergraph.

Apollo GraphQL knows a thing or two about GraphQL at scale:

Apollo’s tooling around the open-source GraphQL specification is
now used by 30 percent of the Fortune 500.

Looking at an Ideal GraphQL

Architecture
All the architecture patterns you explore in Chapter 2 also have a
shared shortcoming: Implementations often suffer from a lack of
consistency. Teams searching for a more effective GraphQL archi-
tecture typically land on two requirements:

CHAPTER 3 Choosing the Right GraphQL Architecture 9

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 » Incremental adoption: For most teams, a “big bang” rewrite
of all existing GraphQL application programming interfaces
(APIs) or all portions of a monolithic GraphQL schema may
not be fruitful or even advisable. Taking an incremental
approach to building the graph allows you to gradually
define services boundaries, identify appropriate connection
points, and learn as you go.
» Separation of concerns: The schema should be separated
by concerns and not types. Types will often contain fields
that can’t be neatly encapsulated within a single service’s
boundaries.

In any event, Apollo sought to meet these requirements

with the release of Apollo Federation in 2019, and in 2022
launched Apollo GraphOS —the platform to build, operate, and
scale the supergraph that consists of

» Apollo Federation: The architecture helps engineers create

the supergraph by using multiple GraphQL APIs. For
example, it lets users combine subgraphs into the
supergraph — both separating concerns and allowing
for incremental adoption.
» Apollo Router: The supergraph runtime library processes
GraphQL queries and then executes them across federated
subgraphs, returning responses to the client.
» Graph Delivery Pipeline: An integrated cloud suite of
developer tools includes a schema registry, GraphQL
integrated development environment (IDE), and
performance insights along with schema checks that ensure
that updating your schema won’t break existing
applications.

The supergraph represents a huge leap forward in GraphQL capa-

bilities, and in contrast to architectures such as schema stitching
(see Chapter 2), the supergraph uses a declarative programming
model, focusing on what needs to be achieved instead of how to
achieve it, that enables each subgraph to implement only the part
of your graph for which it’s responsible. With this approach, your
company can represent an enterprise-scale graph as a collection
of separately maintained GraphQL services.

So why all the fuss? This section shows you all the benefits of the
supergraph.

10 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 Apollo has authored the Principled GraphQL manifesto, which
is brief, inspirational, and definitely worth a few minutes of
your time. Take time to check it out at https://principle
dgraphql.com.

It’s flexible
From a data request/retrieval standpoint, the supergraph is flex-
ible for the front end and does it all, connecting a wide variety of
data and application services. If you’re working at a company that
makes apps for soccer fans, for example, you could use a super-
graph to connect many disparate services, facilitating a complete
view of a fan data: age, income bracket, past ticket orders, and
much more. It can also connect to many different consumers,
powering front-end experiences across many platforms such as
websites, iOS, Android, voice, and watch apps.

It’s robust
The Apollo Router is robust for the back end and both stateless
and horizontally scalable. Capable of serving demanding work-
loads, it powers some of the largest supergraphs in the world.
What’s more, adopting managed federation lets you decou-
ple schema delivery from schema deployment by hosting your
schema in cloud registry, which can be integrated with your con-
tinuous integration and continuous delivery (CI/CD) to validate
that schema changes don’t break your applications.

It’s demand-driven
GraphQL’s value lies in providing an abstraction between services
and consumers, so the schema shouldn’t be tightly coupled either
to one service implementation or one consumer. To accomplish
this, the supergraph utilizes a demand-oriented schema that
provides a superior developer experience for app developers. This
standard helps prevent the graph from becoming coupled to a
service implementation that could change in the future.

It’s agile
The supergraph architecture follows Agile software development
principles. Subgraphs can be added incrementally, and its imple-
mentation can (and should) use a phased approach, with regu-
lar periods to inspect and adapt, making sure value is delivered

CHAPTER 3 Choosing the Right GraphQL Architecture 11

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 to your software team. You can start with just one subgraph and
gradually add more and more subgraphs that represent more
business domains.

It’s fast
Development teams have the ability to work independently
because they can now traverse a single supergraph to get the data
they need. As a result, features go from ticket to production much
faster, increasing the time to value. Backend teams can contribute
independently to the supergraph, and their changes can be auto-
matically composed into the supergraph.

Selecting the Supergraph

So when should you make the move to the supergraph? Whenever
you need to!

GraphQL presents an elegant solution for a common set of prob-

lems that involve querying and retrieving data: problems of
scalability, fast iteration, delivery capacity, and reduced time-
to-market. When led by architects and engineering leaders who
understand the implications, moving to the supergraph can be
transformative. Perhaps most importantly, it can spark conver-
sations that help engineering organizations better understand
the data they provide and consume. Such conversations can help
organizations focus on developing a model that allows them to
work more collaboratively between frontend and backend teams
and ultimately design and develop products in a more customer-
friendly ways.

While each company may have unique considerations in answer-

ing the question of when and how to adopt a supergraph, Apollo
can help if you have questions. Through years of experience,
Apollo recognizes patterns of success when making this shift
and can provide expert guidance about delivering value from the
supergraph on day one. Visit apollographql.com/contact-sales
for more information.

12 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 IN THIS CHAPTER
»» Discussing your architecture

»» Providing guidance for your supergraph

adoption

Chapter  4
Ten Questions for
Proceeding with a
Supergraph

S
oftware architects juggle hundreds of data points in order to
design the digital blueprint for a team or an enterprise. How
do they get many of those key data points? By asking the
right questions. At a strategic level, evolving to a supergraph
implementation can be measured reliably by using a question
matrix. By answering these questions periodically, technology
leaders are better prepared to evaluate when, and how, to proceed
with adopting a Supergraph. This chapter looks at those key ques-
tions, with guidance to follow.

Education plays a key role in the success of a supergraph imple-

mentations. As a starting point for your architecture discussions,
check out the following list of questions:

» So what? Why are you implementing the supergraph? What

business problem are you trying to solve? Is leadership
concerned about software velocity? Is there an initiative to
modernize your technology stack? Adoption should have a
clear business objective. Focus on the benefit — the value

CHAPTER 4 Ten Questions for Proceeding with a Supergraph 13

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
 delivered to the customer — instead of the feature. How you
answer the question “What needs or painpoints motivate
adoption?” is your touchstone as you move to a supergraph.
» Are multiple teams contributing to your graph? If this is
an initial federated implementation, identify your graph
champions — people who advocate for your graph and help
drive adoption — and establish education, review, and
governance processes. Your organization’s Graph
Champions use their foresight and influence to shape an
organization’s technology adoption.
» How many services do you support? More services make
for a larger, more complex GraphQL schema, which means
additional governance for that schema. The supergraph also
provides value as an abstraction layer, allowing you to evolve
your backend services over time without having to make
changes to your clients. A supergraph can make it easier for
many teams to share capabilities across service boundaries.
To review the federated decision matrix, visit www.apollo
graphql.com/docs/enterprise-guide/graphql-
consolidation.
» How many clients consume the application program-
ming interface (API)? What are the demands being put on
the API? What part of your schema can be generalized and
what needs to be specific for a given client. Speaking with
frontend and mobile engineers that consume your graph
helps you determine what their painpoints are and how to
educate them more effectively. A supergraph reduces the
number of bespoke APIs you have to build as client develop-
ers can self-serve capabilities out of your supergraph.
» How distributed are your teams? Companies operating
across multiple time zones benefit from the decoupled/
distributed approach made possible by the supergraph. The
supergraph’s federated architecture empowers teams to
work independently and still contribute to a cohesive whole.
» Who owns what? How are the tasks and responsibilities
divided among your team? The supergraph enables a shared
ownership architecture that offers a more scalable and
flexible solution for most teams.
» Are your teams autonomous? When autonomous teams
working on the same monolithic architecture make changes
according to mismatched schedules, chaos ensues. Slower
release cycles are usually the result.

14 Choosing a GraphQL Architecture For Dummies, Apollo Special Edition

These materials are © 2022 John Wiley & Sons, Inc. Any dissemination, distribution, or unauthorized use is strictly prohibited.
WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.