Overview
Excited to start connecting cookware data directly to recipes? First, let's make sure we're set up for local development.
In this lesson, we will:
- Review the supergraph development kit GraphOS provides
- Use
rover dev
to do local development with our supergraph
The GraphOS supergraph development kit
Apollo GraphOS provides a supergraph development kit that helps developers build and play with subgraphs within a supergraph architecture quickly and easily.
We've already been using parts of the GraphOS supergraph development kit!
Sandbox is one such tool, a special mode of GraphOS Studio that provides us with Explorer (the GraphQL IDE we've been using to build and run queries against our locally-running subgraph), a schema reference, schema checks, and diffs.
Though you didn't create them yourself, both recipes
and kitchenware
subgraphs were bootstrapped using rover template
, providing a starting point for a GraphQL subgraph server with JavaScript.
Note: Curious about other templates for different languages bootstrapping a new subgraph? Check out rover template
in the Apollo documentation.
The last piece of our supergraph development kit is rover dev
.
Using rover dev
rover dev
lets us start a local routerβright on your computer!βthat can query across one or more subgraphs. Each subgraph can be run locally or remotely. It's a supergraph in our local development environment! This lets us implement and test changes before we publish them to GraphOS.
To get started, we'll need the recipes
subgraph running. If you haven't already, start the recipes
subgraph server locally by navigating to your copy of the repo and running npm run dev
.
Next, let's start up the first rover dev
process. This will start the local router and we want it to use our locally-running recipes
server as the first subgraph in the supergraph.
rover dev
needs the following parameters:
rover dev \--name {SUBGRAPH NAME} \--url {ROUTING URL} \--schema {SCHEMA FILE PATH}
The schema file parameter is optional. If the schema file isn't provided, Rover will use introspection on the subgraph server instead. We'll see an example of this when we add the kitchenware
subgraph later on.
Starting the first (main) rover dev
process
Let's give it a try! Open up a new terminal window. Navigate to the recipes
subgraph directory. Then, run the rover dev
command with the appropriate values.
rover dev \--name recipes \--url http://localhost:4001 \--schema ./schema.graphql
After running it, we'll get the following output:
β οΈ Do not run this command in production! β οΈ It is intended for local development.π« starting a session with the 'recipes' subgraphπΆ composing supergraph with Federation v2.3.1π your supergraph is running! head to http://localhost:4000 to query your supergraphπ watching ./schema.graphql for changes
Awesome, looks like our supergraph is running at http://localhost:4000. Let's check it out!
Note: By default, rover dev
runs the supergraph on port 4000. If you would prefer running it on a different port, you can add the additional flag --supergraph-port
(or -p
) and set it to a different value. Just make sure you're not using port 4001 because that's where the recipes
subgraph is running!
In the browser, navigate to http://localhost:4000. We'll see Sandbox connected to the endpoint, ready for us to query our local router.
In the Documentation panel, we can see familiar-looking fields from our recipes
subgraph. Test out a query for a random recipe.
query GetRandomRecipe {randomRecipe {idnamecookingTimeprepTimeservingsinstructionsreadyTimeingredients {text}}}
And we get our recipe data back! π
This first rover dev
process is also our main rover dev
process. It's the process responsible for running the supergraph. If we stopped this process, the supergraph would stop running locally as well!
Starting the second rover dev
process
Time to add the kitchenware
subgraph into the mix! This subgraph is hosted remotely, so the rover dev
command parameters will look a little different. This time, we'll omit the schema file path; Rover will use introspection to get all the details it needs instead.
Open up a new terminal window. If you're using VS Code, we recommend opening it in a split screen view so that both rover dev
processes are side by side.
Let's run this command:
rover dev \--name kitchenware \--url https://poetic-plates-kitchenware-api.herokuapp.com/ \
Note: If you used a different supergraph port with the first rover dev
command, then make sure you run this command with the same supergraph port! This ensures that both processes are able to communicate with each other.
After running the command, we should get the following output:
WARN: if you would like to watch '--schema ./schema.graphql' for changes instead of introspecting every second, re-run this command with the '--schema ./schema.graphql' argumentπ polling https://poetic-plates-kitchenware-api.herokuapp.com/ every 1 secondπ€ adding the 'kitchenware' subgraph to the sessionβ successfully composed after adding the 'kitchenware' subgraph
Note the first line indicating that rover dev
is using introspection instead of watching for changes in a local file.
If you had both terminals side by side, you might have also noticed that the first rover dev
process has two additional lines:
πΆ composing supergraph with Federation v2.3.1β successfully composed after adding the 'kitchenware' subgraph
The addition of the new subgraph went without a hitch! We've just done the equivalent of what we did in lesson 3 when we added the kitchenware
subgraph using Studio, but locally!
When we head back over to the supergraph on http://localhost:4000, we can see new fields were added, belonging to the kitchenware
subgraph . And we can make the same query we did in the last lesson, just to double check everything is working smoothly.
query SkilletAndRecipes($name: String) {cookware(name: $name) {namedescriptioncleaningInstructions}recentlyAddedRecipes {name}}
And under the Variables section:
{"name": "cast iron skillet"}
Run the query and... data! πYou can confirm the same data was returned in Studio as it is in Sandbox.
We're now free to make any changes we'd like to in the recipes
subgraph, and see for ourselves how the router would handle them. We can even spin up a whole new subgraph (maybe cookbooks? Chef information? Where to find the best ingredients?) and add it to our local supergraph.
This is your playground to explore in, to test new concepts, and dream up new featuresβ all without impacting the production supergraph!
Practice
rover dev
not do?Key takeaways
- The GraphOS supergraph development kit includes the following: Sandbox,
rover template
androver dev
. rover dev
lets us start a local router that can query across one or more subgraphs.- To use
rover dev
, we need each subgraph's name, the URL where it's running, and (optionally) the path to the schema file. If the schema file is not provided, Rover will use introspection on the subgraph instead. - We can add however many subgraphs we want to our local router using
rover dev
.
Up next
We have everything we need to get started on our changes! Let's turn our focus back to that dream query that connects data between a recipe and the cookware it uses. For this, we'll need to dive into the supergraph architecture and how the router handles coordination across subgraphs.
Share your questions and comments about this lesson
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.