6. Apollo Sandbox Explorer


It's time to write some queries, and see our server return some (hardcoded) data!

In this lesson, we will:

  • Learn how to navigate Explorer
  • Save for future use

🚀 Exploring our first query

To write our test , we'll use Apollo Sandbox. Sandbox is free to use and doesn't require an account. It's part of the platform, and helps with local graph development.

Apollo GraphOS is a complete cloud platform for building, managing, and scaling your . provides a set of tools and services so that product developers can focus on building better apps, faster.

With Sandbox, we can load a 's schema and explore it using some cool features such as a schema reference and the Explorer.

The Explorer is a powerful web IDE for creating, running, and managing . It lets us build operations easily and quickly, look at our operation history, peek at response hints and share operations with others.

Let's make sure our server is running, then open up a browser and head to Apollo Sandbox Explorer!


Exploring the Explorer

When we land in the Explorer, we'll see an interface that's mostly empty.


The Apollo Sandbox Explorer, not connected to any API

This is because it hasn't yet connected to a API—specifically, the one we've just spent some time building!

Let's get that hooked up first. At the top of the Explorer, we'll see an input for the location where our server is running. By default, our is available to on http://localhost:8080/graphql, so we can paste that URL into this input.


After a moment, we should see the little dot turn green—this means the Explorer has connected successfully! And we'll also see that the UI has updated with some new elements. Let's explore those next.


The Apollo Sandbox Explorer, connected to the running DGS server endpoint

Building a query

The Operation panel in the middle is where we create queries. The Explorer might have already filled in a default . Let's open up a new workspace tab with the + button for a fresh start.

We can write the manually, or add from the Documentation panel on the left: it enables you to drill down into your schema's , starting at the entry points of the Query type.


The Explorer, with the Documentation panel highlighted to show the Query entrypoints

Clicking on the plus (⊕) button next to a automatically adds that field to our current . This is a handy way to assemble complex queries without needing to remember your schema's exact structure or syntax.

Let's add featuredListings to our first .


Adding the featuredListings field to the Operation panel

We'll see that the Documentation tab has updated, showing us the different that we can add to get data for each object returned as a Listing type. We can click on the plus button by id to add it to our .


Highlighting the id field we want to add to our query

This automatically updates the Operation panel with the we selected.


Adding the id field to the Operation panel

Here's what our should look like:

query FeaturedListings {
featuredListings {

At the top of the Operation panel is the button to run our . Let's click it now and see what happens:


Running the operation and seeing featured listing data in the Response panel

The Response panel on the right contains an object with our list of listing IDs!

Response object
"data": {
"featuredListings": [
"id": "1"
"id": "2"

Adding all fields

Right now, we've selected only the featuredListings and id , but the Explorer also has a way to add all fields to an at once. When we click the dropdown by the Fields subheading, we'll see that we have two options.


Clicking the Fields dropdown in the Documentation panel

First, we have the option to Select all scalar fields. This will select all of the on the Listing type that return a value that does not have additional sub.

Click Select all scalar fields. We'll see the title, numOfBeds, costPerNight, and closedForBookings have been added to our .


All scalar fields added to the query

All of our are taken care of, but we'll notice there's a second option in the dropdown: Select all fields recursively. This option lets us add all of a type's , and any of those field's subfields, all at once; this is particularly important when a returns an that has its own set of fields. We'll see this shortly when we add to our schema!

Running the query

Your completed should match the following:

query FeaturedListings {
featuredListings {

Take it for a spin in the Explorer!

Here's the response we should see:

Saving an operation

We've already spent the time building out the FeaturedListings , so let's take advantage of another Explorer feature that makes constructing it again even easier. (You'll need a Studio account for this part!)

At the top of the Operation panel, we'll find a save icon button.


The Save dropdown in the Explorer, showing the Save as option

Clicking the Save as option from the dropdown opens a modal where we can give our a name, and save it to an operation collection.

With a collection, we can store a group of in a place that's quick to access when we want to test future changes to our schema.

Let's start by giving our the name FeaturedListings so that we can locate it when we need it again. Next, in the Select a collection dropdown, let's select the option under Sandbox to create a new default collection.


Saving the FeaturedListings operation in a new Sandbox collection

After we click the Save button, we'll see that our 's tab now has the name we assigned to it! Additionally, we'll see a bookmark icon that indicates that this operation is saved to a collection.


A tab showing the named operation and a bookmark icon

We can use the panel on the left of the Explorer to access that we've saved to a collection. Clicking the bookmark icon at the top of the menu opens up all of our Operation Collections, where we can see our FeaturedListings has been saved for quick access!


Clicking the bookmark icon to access saved operations

The Schema tab

Before we leave the Sandbox environment, let's check out our schema; it's accessible under the first tab in our main navigation.


A screenshot of the Schema page in Sandbox, with the FeaturedListings field outlined

Here we have a full view and reference into our schema! It's pretty sparse right now, but we can see our Query type with a featuredListings that returns a [Listing!]! type.

In the tab, we can also see the schema in SDL syntax. This is the actual schema that our server is running its requests against!


SDL page


Which of these are benefits of using the Apollo Sandbox Explorer?

Key takeaways

  • The Explorer is a full-fledged IDE that introspects a running server's schema and allows us to build and send queries.
  • We can use collections to store operations we've already built for future use.

Up next

The Explorer can do so much more, but this is all we'll cover for now. It's time to move onto our next topic—hooking up a real !


Share your questions and comments about this lesson

This course is currently in

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