6. Query building in Apollo Sandbox
5m
You're currently on an older version of this course. View course changelog.

🚀 Exploring the Apollo Sandbox

So far, we've been using the Explorer page of to build and test queries. But Sandbox can do even more! Let's take a quick detour to explore some of the other tools in Sandbox.

First, we need to start our server. Open a terminal window, navigate to the server folder with cd server, then run npm start.

With the server running, we can go to the Sandbox in the browser by going to http://localhost:4000, then clicking Query your server to see our in action.

The Schema page

Let's check out the schema page (the first tab on the left sidebar).

http://localhost:4000
Screenshot of Apollo Studio, opened to the Schema page

This page gives us useful information about the current status of our schema. Because we're using Sandbox, Apollo Studio automatically polls our locally running server for schema changes.

The Schema page has two main tabs: Reference and .

The SDL tab shows you your schema represented in . It should look familiar from your own schema.js file!

The Reference tab shows you a high-level overview of your schema, including its defined types and . Notice the Play button to the right of the ? Click it and see what happens. It sends us directly to the Explorer, with the Documentation sidebar conveniently opened to the corresponding !

🛠️ Building our query

Now that we're back in the Explorer page, let's get back to building our . Clicking the plus button () on the track , we start to see our come together in the Operation panel.

http://localhost:4000
Screenshot of Apollo Studio Explorer with the Operation panel pre-filled with the `track` field

First let's rename our to better explain what it's for, so we'll replace Query with GetTrack.

So far, the Operation panel of the Explorer should contain this:

query GetTrack($trackId: ID!) {
track(id: $trackId) {
}
}

You'll notice something new here: a dollar sign ($) followed by the name trackId.

💰 Variables

The $ symbol indicates a in . The name after the $ symbol is the name of our , which we can use throughout the . After the colon is the variable's type, which must match the type of the we'll use it for.

Illustration to explain the syntax of GraphQL variables

are great—they let us pass values dynamically from the client-side so we don't have to hardcode values into our . We'll use them every time we create a query with arguments.

Variables
Variables are denoted by the 
 
symbol. They are used to provide dynamic values for 
 
to avoid including 
 
 values in a query. Each one's type must match the type specified in the 
 

Drag items from this box to the blanks above

  • resolvers

  • name

  • @

  • hardcoded

  • !

  • $

  • arguments

  • graph

  • null

  • schema

In our case, we have a called trackId that the Explorer set up for us down in the Variables section. Right now, it's set to null, but let's replace it with the track ID we've been testing so far: c_0.

http://localhost:4000
Screenshot identifying the Variables panel in the Explorer, with the track id of 'c_0'

Add the following to the Variables section in the Explorer:

{ "trackId": "c_0" }

Before we start adding all the we need from our initial mockup, let's start small with just returning the id and the title.

The Operation panel of the Explorer should now look like this:

query GetTrack($trackId: ID!) {
track(id: $trackId) {
id
title
}
}

When we click on the run button, we see the data we're expecting! Awesome, let's add the rest of our by clicking the dropdown by the Fields subheading. When we click Select all fields recursively from the dropdown, we'll see all of our and subfields have been added to the .

http://localhost:4000
Screenshot of the Fields dropdown, selecting the option to add all fields recursively to our query

The full should look like this:

query GetTrack($trackId: ID!) {
track(id: $trackId) {
id
title
author {
id
name
photo
}
thumbnail
length
modulesCount
numberOfViews
modules {
id
title
length
}
description
}
}

Let's click on the Run Query button again… it looks like we get the complete track, but it's a bit tricky to read as a JSON object. The Explorer has a nice option to format the response as a table.

http://localhost:4000
Screenshot of the Explorer highlighting how to format Response data in a table view

And now we can clearly see the track that we need, along with all the details for each module! Nice!

http://localhost:4000
Screenshot showing the Explorer with a complete query and successful response
Code Challenge!

Build a query called getMission. This query uses a variable called isScheduled of type nullable Boolean. It retrieves a mission using the scheduled argument set to the isScheduled variable. It retrieves the mission's id and codename.

Our server is ready for our client's queries, so let's hop on over to client-land and work on the UI.

Previous

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.