5. Resolving a mutation successfully
3m

🧪 Mutation resolvers

We've set up our to make a PATCH call to our REST API. Now it's time to write to put our to work.

In the server/src folder, let's open up the resolvers.js file. We need to add another entry to our resolvers object for our .

We can add it just below our Query , and we need to give it the same name as in our schema, which is Mutation (note the capital M!).

const resolvers = {
Query: {
// ... query resolvers
},
Mutation: {
// where our new resolver function will go
},
};

Inside this Mutation object, we'll add the function for our , which also needs to have the same name as in our schema incrementTrackViews. And of course, let's add a helpful comment at the top.

// increments a track's numberOfViews property
incrementTrackViews: (parent, args, contextValue, info) => {},
Which of these are true about the structure of the resolvers object?

We won't need the parent in this , because it's for a root in our schema. By convention, we'll just add an underscore. We do need to destructure the second parameter args to retrieve the id of the track we're updating. As usual, we'll also destructure the third parameter contextValue for the dataSources object. And finally, we have no need for the fourth parameter info.

Here's what our signature looks like now:

server/src/resolvers.js
incrementTrackViews: (_, { id }, { dataSources }) => {
// where we'll call the TrackAPI
},

In the body of the , we want to call the method we added to our TrackAPI class. As we saw in Lift-off II, we get access to an instance of that class, trackAPI, through the dataSources object because we configured it in the options.

So inside the incrementTrackViews body, we'll call dataSources.trackAPI.incrementTrackViews, passing it the id from args.

dataSources.trackAPI.incrementTrackViews(id);

So far, we've always immediately returned the results of our TrackAPI calls, because the results match the structure required by our schema.

However, in this case, we have three required by our schema that are not present in the returned response: code, success and message. This makes sense because they are tied to the REST status itself, so we need to set those three based on that status.

Why can't this resolver immediately return the results of the TrackAPI call in this case?

📄 Fulfilling the schema requirements

First, let's wait for the TrackAPI call to finish returning the data. We can do this by making the function async, then storing the results in a called track, making sure to await the results.

incrementTrackViews: async (_, {id}, {dataSources}) => {
const track = await dataSources.trackAPI.incrementTrackViews(id);
},

Next, let's return an object with all the properties needed to fulfill our schema. For now, we'll assume that the API call was successful, and worry about the error handling in the next lesson.

return {
code: 200,
success: true,
message: `Successfully incremented number of views for track ${id}`,
track,
};

So here the code will return 200, the success property will be set to true, and we can return message to show that the number of views was successfully incremented for this specific track ID. And finally, we can return the modified object, track.

In the end, the resolvers object should have a new entry that looks like this:

Mutation: {
// increments a track's numberOfViews property
incrementTrackViews: async (_, { id }, { dataSources }) => {
const track = await dataSources.trackAPI.incrementTrackViews(id);
return {
code: 200,
success: true,
message: `Successfully incremented number of views for track ${id}`,
track,
};
},
},
Code Challenge!

Add a resolver for the new assignSpaceship mutation provided in the schema, using arrow function syntax. Use the dataSources.spaceAPI class and its method assignSpaceshipToMission, which takes the spaceshipId and the missionId as arguments (in that order). This method returns an object with the newly updated spaceship and mission. Follow the schema requirements to return an object for the successful result. code should be 200, success should be true and message should say Successfully assigned spaceship ${spaceshipId} to mission ${missionId}

All right, we've got our successful case resolved, but what happens when our TrackAPI throws an error? Let's take care of this in the next lesson.

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.