Exercise: Creating a supergraph
🎯 Goal: Create a supergraph on GraphOS using your subgraph'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 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
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 namerecipesWhat'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?
AnswerThe 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.
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.
cors:origins:- https://studio.apollographql.comheaders:subgraphs:recipes:request:- propagate:matching: ".*"
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
.
cors:allow_any_origin: 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.