5. Sharing your supergraph


Poetic Plates is meant to be a public API, ready to receive and resolve requests from anyone through a web app, mobile app, or another API– the possibilities are endless!

To enable this, we want to allow folks to easily explore the and query the . We've seen how straightforward it is to build queries using , so we'll enable this for others as well!

We also want to allow client app developers to send requests to the . By default, the current CORS policies are blocking them from doing so.

In this lesson, we will:

  • Create a public variant
  • Configure the cloud router to accept requests from any origin

Graph variants

A variant represents a different environment where the runs. For example, you could have a variant for staging or pre-production, a common environment where we can test our changes before they go live. You could have another variant for production, the version that clients are using and can be confident in.

In , each variant of a has its own , metrics, change history, and history.

So far, we've been working with only one version of our : the version that's currently running in production. This is actually our very first variant, and its default name is main. By default, this variant is private and only visible to members of our Studio organization.

Note: Although we're working in local-land, we're connected to production data. In the real world, you'll probably have a separate variant to handle local queries and s so that production data isn't compromised. You can learn more about graph variants and workflows in the Voyage III course.

We want to allow folks who want to use our API to explore the freely and send queries using , so we'll need to make this variant public.

By making a public variant, our API consumers will be able to see these pages:

  • Home: shows the variant's README. Much like a repository README, this is helpful for introducing folks to the Poetic Plates API, onboarding them to get started with it.
  • Schema: shows the types and fields that make up the supergraph.
  • Explorer: enables consumers to send queries to the supergraph, just like we have!
  • Changelog: shows the recent changes to your supergraph.

The pages showing your 's metrics (Fields, Operations) and settings won't be viewable!

Creating a public variant

Let's go ahead and make our main variant public.

  1. Go to your variant's Settings page and open the This Variant tab.

  2. Find the Public card and click Change.


    Saving public variant settings

  3. Select On and save your changes.


    Saving public variant settings

  4. You'll notice that the header at the top now shows a button labeled "Public". Click on it to navigate to the public version of the .

Notice that we're only able to see the four pages we mentioned earlier. We're good to go and we can share this public variant link for others to explore!

Bonus: Go ahead and edit your 's README! In the README page, click on the pencil icon to edit the README. Include any information that is relevant for developers working with your . How do you want to introduce them to it? What is important for them to know? What queries can they get started with?

Configuring the cloud router cors options

Next, we need to allow any web-based app consumer to send requests to the . We want Poetic Plates to be used widely, after all! We'll need to configure the cloud cors options to enable this.

Back in Studio, in our 's Settings page, under This Variant we'll click on the Cloud Routing tab.


The Router Configuration page in Apollo Studio

This is where we can configure how the cloud runs. We've already got some default configuration under the Router Configuration YAML section.

Router Configuration YAML
- https://studio.apollographql.com
- propagate:
matching: ".*"

The first key, cors contains another key (origins), which contains the list of URLs that are allowed to query the . Right now, only Studio is allowed to query the !

We can also see headers configuration for the recipes subgraph, which propagates every single request header. We won't worry too much about that, but we do want to change the cors property!

Let's remove the origins list because we're not going to specify every single origin to allow. Below (still nested within the cors property), we're going to add a new property called allow_any_origin and set it to true.

Router Configuration YAML
allow_any_origin: true

Then, hit Save.


The Router Configuration page in Apollo Studio, with localhost added and the Save icon emphasized

If we didn't set this option, client app developers would see an error in their browser, noting that their localhost or production URL has been blocked by CORS policy.

Now you're free to share your URL with your client app developers!


Which of the following statements about the cloud router are true?
Which of the following statements are true about public variants?

Key takeaways

  • To enable others to explore and query a public-facing API, you can create a public variant in Studio.
  • To enable any web app consumer to connect to your public-facing API, you can configure the cloud router's cors settings and set allow_any_origin to true.

Up next

We can share our to the world, amazing! Let's learn how we're going to monitor the usage of our now that it's out in the wild.


Share your questions and comments about this lesson

This course is currently in

. Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.