Docs
Try Apollo Studio

Cloud routing for supergraphs

In GraphOS


Cloud supergraphs are available to organizations with new Apollo Serverless plans. They are not available to organizations with an Enterprise plan or a legacy Free or Team plan.

See details about plans.

When you create a cloud supergraph with Apollo Studio, GraphOS automatically provisions and manages a router that sits in front of your GraphQL API:

Your infrastructure
GraphOS
Your GraphQL API
Router
Clients

Clients send operations to your router's public endpoint, instead of sending them directly to your API. This way, you can later add more APIs to your supergraph, and clients can query data from all of them with a single request to the router:

Your infrastructure
GraphOS
Subgraph A
Subgraph B
Router
Clients

With this supergraph architecture (also known as Apollo Federation), each of your individual GraphQL APIs is known as a subgraph. Your router takes care of executing each incoming client operation across the appropriate combination of subgraphs, and then it merges subgraph responses into a single response for the client.

Initializing your router

Your router is provisioned automatically whenever you create a cloud supergraph in Studio, or whenever you create a new variant for an existing cloud supergraph. Each variant has its own distinct router.

When you first create your variant, the router provisioning process can take a few minutes. If this process hasn't completed yet for a particular variant, an INITIATING ENDPOINT label is shown at the top of the variant's page in Studio:

Label in Studio indicating a router hasn't finished provisioning

Configuring your router

See Configuring cloud routing.

Cloud routing FAQ

What happens if my cloud router goes down?

If your supergraph's cloud router goes down, queries sent to it will fail until service is restored. However, every cloud router has redundant machines in place to help prevent this.

How is my data protected with cloud routing?

The entire GraphOS platform (including its cloud routing infrastructure) is SOC 2 Type 2 certified. Secrets are encrypted both in transit and at rest, and they are available only inside the runtime environment where users have total control over when those secrets are resolved in configuration.

The Apollo Router (the underlying technology for cloud routing) has been tested and audited by Doyensec, with no issues.

How are cloud routers hosted?

Apollo works with major public cloud providers to deliver GraphOS cloud routing.

Which regions are available for cloud routers?

During the preview phase, infrastructure for cloud routing is in Chicago, USA. Our infrastructure has interconnects with the major public cloud providers, so latency is minimal.

For example, latency between Chicago and AWS in Virginia is approximately 10ms. We will likely be adding available regions in the coming months, so please reach out if you have specific requirements.

Can I choose my cloud router's region?

Not yet, but we're working to make additional regions available. If there's a region you'd like to see supported, let us know.

Will cloud routing support multi-region and/or edge caching?

Our goal with cloud routing is to deliver global, industry-leading graph performance. During the preview phase, routing infrastructure is hosted in one region, with plans to expand globally and add caching support in 2023.

Does GraphOS also host my individual subgraphs?

No. GraphOS only hosts the runtime for your supergraph's cloud router. GraphQL servers for your individual subgraphs are still hosted in your infrastructure.

Which GraphQL server libraries are compatible with cloud routers?

Cloud supergraphs use Apollo Federation 2 for their core architecture. Many GraphQL server libraries support Federation 2.

Your GraphQL API does not already need to be using Apollo Federation to add it to a cloud supergraph.

Edit on GitHub
Previous
Self-hosted setup (enterprise only)
Next
Configuring cloud routing