Exercise: Creating a supergraph

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

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

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

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 subgraph? Think: what business domain is it focused on? Here's the subgraph name we used:

   Subgraph name

   recipes

   Copy

   Show code

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

   Answer

   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.

   Copy

   Show code

Hello, supergraph! Configuring CORS

Currently, our supergraph is ready to be queried—but only through Studio. This is because the cloud router 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 supergraph'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 variant-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.

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

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

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.

Then, hit Save.

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.