8. Querying live data
2m

We've implemented our resolvers and our data source, and we've connected them up to the server. Time to find out if everything works together to actually serve live data.

You can trace your query's journey all the way back to the client and expect to see the live data in your browser, but there is actually a secret shortcut to server-land: the Apollo Studio Explorer! It lets you connect to the server currently running on localhost:4000 and helps you build queries quickly to test out.

Hand-drawn illustration depicting a shortcut to server land through Apollo Studio Explorer as an alternative to starting from client-land

Our server is still running, so you should be seeing a message in the console saying the server is indeed running and that we can start querying with the Explorer at the link provided.

Head over to Studio using that link, or visit studio.apollographql.com/dev in your browser.

If you haven't created an account yet, head over to this Lift-off Part 1 lesson to walk through the process. You should have a development graph connected to http://localhost:4000.

We can use our example query from Part 1 to test out our new resolver (code snippet below).

query getTracks {
tracksForHome {
id
title
thumbnail
length
modulesCount
author {
id
name
photo
}
}
}

Let's go ahead and run it... and we get the data that's returned by our resolver! 🎉 We can also see that we only get exactly the data we queried for, nothing extra, even though our REST endpoint wasn't structured that way. This means that the resolver has completed its mission, and so have we!

Code Challenge!

In the Apollo Studio Explorer, test the same tracksForHome query we used in Part 1 (or copy the one above and paste it in the Explorer). Run the query and copy-paste the last tracks entry below.

Let's click on the query button once more. Did you notice how fast we got the response the second time? The first one took about half a second, then this one returned in just a few milliseconds. This is thanks to our RESTDataSource's built-in resource caching.

Just for the fun of comparing, you can take a look at the fetch implementation below. A new field has been added called tracksforHomeFetch to our schema. The resolvers are using node-fetch instead of the RESTDataSource. For each call, the response takes the same amount of time, about half a second. Much less efficient, now we really see why we should keep using the RESTDataSource implementation!

// schema
const typeDefs = gql`
type Query {
tracksForHome: [Track!]!
tracksForHomeFetch: [Track!]!
}
// ...
`;
const resolvers = {
Query: {
tracksForHome: () => {
// ...
}
tracksForHomeFetch: async () => {
const baseUrl = "https://odyssey-lift-off-rest-api.herokuapp.com";
const res = await fetch(`${baseUrl}/tracks`);
return res.json();
},
},
Track: {
// using fetch instead of dataSources
author: async ({ authorId }, _, { dataSources }) => {
const baseUrl = "https://odyssey-lift-off-rest-api.herokuapp.com";
const res = await fetch(`${baseUrl}/author/${authorId}`);
return res.json();
// return dataSources.trackAPI.getAuthor(authorId);
},
},
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

You can find the full code example in the repo's fetch-example branch in the final folder.

Which of these have we demonstrated in the Explorer by comparing a query using the RESTDataSource with a query using a simple fetch approach?

Previous
Next