Introduction

Are you tired of writing resolver code and hosting yet another subgraph server just to add a few fields to your graph from a REST API? Or maybe you already have an existing REST API that's working perfectly fine and want to get started on a new graph. We've got you covered!

In this course, we'll learn how to plug in an existing REST API into a graph using Apollo Connectors.

We'll use two schema directives to implement our connectors: @connect and @source. We'll get equipped with useful tools for our developer workflow, including using Rover for local supergraph development and Explorer to debug connector network calls and examine query plans. By the end of the course, we'll have a working graph powered by a REST API, without writing a single line of resolver code!

Ready? Let's get started! 🚀

In this lesson, we will:

• Identify the key pieces of a supergraph architecture
• Understand where Apollo Connectors fit in

A federated GraphQL API: the supergraph

First, let's take a look at how a GraphQL API currently works.

When a client needs some data, it sends a GraphQL operation to the GraphQL server. The server uses its schema, resolvers, and data sources to retrieve and resolve that data, then sends it back to the client. It's a pretty great experience!

This setup works well for smaller projects or teams, but what happens as our API grows? As more teams start adding types, fields, and features to our schema, our API becomes harder to manage, scale, and deploy. This is a common bottleneck problem with monolithic backend services.

To solve this problem, we can divide our API's capabilities across multiple GraphQL-powered microservices, with each one taking responsibility for a different part of our API's schema. When we adopt this federated architecture, each of our microservices is called a subgraph, and together, they form the foundation of our supergraph.

If we split our API's capabilities between lots of different microservices, how do clients query across all of them? For that, we need the other piece of our supergraph: the router.

The router knows about all of our subgraphs, and it also knows which subgraph is responsible for each field in our API's schema. Clients send queries to the router, and the router intelligently divides them up across the appropriate subgraphs.

The router acts as the single access point for our API, kind of like an API gateway. This means that clients don't need to worry about communicating with our individual subgraphs!

Zooming in on subgraphs

By splitting up our schema into subgraphs, backend teams can work on their own subgraph servers independently, without impacting developers working on other subgraphs. And since each subgraph is a separate server, teams have the flexibility to choose the language, infrastructure, and policies that work best for them.

These are great benefits and have proven very useful for enterprise companies and products.

But what if we could shorten the subgraph development process—and connect directly to the datasources that power these subgraphs?

Introducing Apollo Connectors

Apollo Connectors enable us to easily integrate REST APIs into the supergraph, without leaving the comfort of the schema!

When implementing a subgraph server, the process typically begins with the schema: we define our types and fields. Then, we need to select a language and GraphQL server framework to develop in. Each of our schema's types and fields needs resolver functions, which contain the logic to populate the data for that particular type or field by connecting to the necessary data sources. These data sources are, more often than not, existing REST APIs. To complicate matters further, the REST API responses will often differ greatly from the shape of our schema; this leaves us writing even more code just to map data into the types and fields the GraphQL server expects.

With Apollo Connectors, we can skip the time-intensive steps of spinning up a subgraph server and writing resolver code. Instead, we can work directly in the schema to map our REST API data to our schema's types and fields. With this connectors-enabled schema, the router creates a query plan that will directly call our REST API endpoints, plucking out the properties we've defined. That's right, all we need is the schema!

Practice

Key takeaways

• In a federated GraphQL architecture (also known as the supergraph), a client sends a query to the router, which intelligently divides it up and executes it against smaller GraphQL-powered microservices called subgraphs.
• Apollo Connectors enable us to easily integrate REST APIs into the supergraph by working directly in the schema, skipping the process of spinning up a subgraph server and writing resolver code.

Up next

Let's set up the project we'll be working with for this course (a space travel booking API) so we can get hands-on with Apollo Connectors!