4. Local development with rover dev
4m

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 provides a supergraph development kit that helps developers build and play with subgraphs within a architecture quickly and easily.

We've already been using parts of the development kit!

Sandbox is one such tool, a special mode of Apollo Studio that provides us with (the GraphQL IDE we've been using to build and run queries against our locally-running subgraph), a reference, , 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 development kit is rover dev.

Using rover dev

rover dev lets us start a local - right on your computer! - that can query across one or more subgraphs. Each subgraph can be run locally or remotely. It's a in our local development environment! This lets us implement and test changes before we publish them to .

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.

Task!

Next, let's start up the first rover dev process. This will start the local and we want it to use our locally-running recipes server as the first subgraph in the .

rover dev needs the following parameters:

rover dev \
  --name {SUBGRAPH NAME} \
  --url {ROUTING URL} \
  --schema {SCHEMA FILE PATH}

The file parameter is optional. If the file isn't provided, Rover will use 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:3000 to query your supergraph
👀 watching ./schema.graphql for changes

Awesome, looks like our is running at http://localhost:3000. Let's check it out!

Note: By default, rover dev runs the on port 3000. 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:3000. We'll see Sandbox connected to port 3000, ready for us to query our local .

In the Documentation panel, we can see familiar-looking s from our recipes subgraph. Test out a query for a random recipe.

query GetRandomRecipe {
  randomRecipe {
    id
    name
    cookingTime
    prepTime
    servings
    instructions
    readyTime
    ingredients {
      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 . If we stopped this process, the 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 file path; Rover will use 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 port with the first rover dev command, then make sure you run this command with the same 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 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 on http://localhost:3000, we can see new s 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) {
    name
    description
    cleaningInstructions
  }
  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 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 .

This is your playground to explore in, to test new concepts, and dream up new features– all without impacting the production !

Practice

Which of the following does rover dev not do?

Key takeaways

  • The GraphOS supergraph development kit includes the following: Sandbox, rover template and rover 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 architecture and how the handles coordination across subgraphs.

Previous
Next

Share your questions and comments about this lesson

This course is currently in

beta
. 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.