5. Exercise: Creating a supergraph

Exercise: Creating a supergraph

🎯 Goal: Create a on using your 's routing URL (where it's running on Railway!). This will be the start of your Poetic Plates GraphQL API.

You'll need a Studio account with the Serverless plan.

If you already have a account with existing graphs, click the Create New Graph button. Then, walk through the steps to create a .

If you see the flow below, you're in the right place!


Create a new graph

If you don't see that screen, then follow the "Before you start: Check your plan" section above. Studio will show us an "Almost done!" message, so we'll keep going with the slides while we wait for it to do its thing. It takes a few minutes.

Bonus questions to think about

  1. What's a good name for this first ? Think: what business domain is it focused on? Here's the subgraph name we used:

    Subgraph name
  2. What's the difference between the ID and the supergraph name? When/where would the ID or the name be used in: the developer workflow? ?

    The supergraph ID will be used to reference your supergraph from various tools later on.
    It CANNOT be changed.
    The supergraph name can be changed at any time.
    It's displayed throughout Studio.
    It's usually how you refer to your supergraph with your teammates.
What are the 'advanced options' for creating a supergraph in Step 1 for?

Hello, supergraph! Configuring CORS

Currently, our is ready to be queried—but only through Studio. This is because the cloud we've set up for our supergraph needs to be specifically configured to allow other origins to access it.

We can update these settings right in Studio. We'll navigate to our newly-created 's Settings page. There, we'll find two tabs—one for our graph's variant, and one for the graph as a whole. We're able to configure CORS on a -by-variant basis, because different versions of our graph might serve different audiences.

From here, we can click into the Cloud Router option, and scroll down to the section titled Router configuration YAML.


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 router!

We can also see headers configuration for the recipes , 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.