Overview

We added the User interface as well as the Host and Guest entities to the accounts subgraph schema, but they need accompanying resolvers! In this lesson, we will:

• Copy over the relevant data sources
• Implement resolvers for root fields
• Implement the interface's __resolveType resolver
• Implement the __resolveReference resolver functions for the entities
• Return a representation of the entity from the monolith subgraph

Creating data sources

Currently, our accounts subgraph doesn't have any data sources connected yet. However, we know that it needs the accountsAPI data source to get access to user and account information.

1. Let's look at the datasources/accounts.js file in the monolith directory. Copy the file and paste it into the subgraph-accounts/datasources directory. This lets us access the data source in the accounts subgraph.

   You can also delete the placeholder datasources.js file in the subgraph-accounts/datasources directory while you're here.

2. Open up subgraph-accounts/index.js and add the import at the top:

   subgraph-accounts/index.js

   const AccountsAPI = require("./datasources/accounts");

   Copy

3. Then, find the line where we return the contextValue object for resolvers to use. We'll set up the AccountsAPI inside the dataSources object.

   subgraph-accounts/index.js

   return {
     ...userInfo,
     dataSources: {
       accountsAPI: new AccountsAPI(),
     },
   };

   Copy

4. Let's not forget to include the cache when we initialize the AccountsAPI, enabling the RESTDataSource cache.

   subgraph-accounts/index.js

   return {
     ...userInfo,
     dataSources: {
       accountsAPI: new AccountsAPI({ cache }),
     },
   };

   Copy

Great, we can now use this data source in our resolvers!

Resolving the Query and Mutation fields

Let's first tackle the resolvers for our root fields.

1. Open up the resolvers.js file in the accounts subgraph, and delete the default query that came with the template, along with its _todo resolver function.

   subgraph-accounts/resolvers.js

   const resolvers = {
   -  Query: {
   -     _todo: () => "TODO",
   -  },
   };

2. Find the resolvers for Query.user, Query.me and Mutation.updateProfile in the monolith/resolvers.js file (or you can copy them below). We'll paste these into the resolvers map in the accounts subgraph.

   subgraph-accounts/resolvers.js

   Query: {
     user: async (_, { id }, { dataSources }) => {
       const user = await dataSources.accountsAPI.getUser(id);
       if (!user) {
         throw new Error("No user found for this Id");
       }
       return user;
     },
     me: async (_, __, { dataSources, userId }) => {
       if (!userId) throw new AuthenticationError(authErrMessage);
       const user = await dataSources.accountsAPI.getUser(userId);
       return user;
     },
   },
   Mutation: {
     updateProfile: async (
       _,
       { updateProfileInput },
       { dataSources, userId }
     ) => {
       if (!userId) throw new AuthenticationError(authErrMessage);
       try {
         const updatedUser = await dataSources.accountsAPI.updateUser({
           userId,
           userInfo: updateProfileInput,
         });
         return {
           code: 200,
           success: true,
           message: "Profile successfully updated!",
           user: updatedUser,
         };
       } catch (err) {
         return {
           code: 400,
           success: false,
           message: err.message,
         };
       }
     },
   },

   Copy

Resolving the interface

Next let's tackle the User interface, which needs a resolveType. We actually already have one defined in the monolith subgraph, so all we need to do is copy that function over to the accounts subgraph.

Resolving entities

As we covered in Voyage I, subgraphs that contribute fields to an entity use a special resolver called a reference resolver to resolve entities. This function enables the router to directly access entity fields that each subgraph contributes.

We'll implement reference resolvers for the Host and Guest entities in the accounts subgraph.

1. Inside the resolvers object, add a reference resolver for the Host type:

   subgraph-accounts/resolvers.js

   Host: {
     __resolveReference: (user, { dataSources }) => {
       return dataSources.accountsAPI.getUser(user.id);
     },
   },

   Copy

   We're using the accountsAPI data source's getUser method and passing it the id of the user to retrieve that user's information.

2. Let's add a similar reference resolver for the Guest type.

   subgraph-accounts/resolvers.js

   Guest: {
     __resolveReference: (user, { dataSources }) => {
       return dataSources.accountsAPI.getUser(user.id);
     },
   },

   Copy

Perfect, the entities have their reference resolvers!

We've covered all of our accounts schema fields with resolvers. One last thing before we test out our changes...

The monolith subgraph

In a previous lesson, we mentioned that we could include other fields in the accounts subgraph, specifically: Listing.host, Booking.guest and Review.author. We're going to keep these fields in the monolith schema for now (eventually they'll migrate their way over to listings, bookings and reviews subgraphs respectively), but we can update the resolvers.

Currently, the resolver for each of these fields uses the Accounts API. For example:

We want to start removing this dependency on the Accounts service (after all, that's what the accounts subgraph is for!). So we'll remove these calls to the accountsAPI and return entity representations instead.

Returning entity representations

If you recall from Voyage I, an entity representation is an object that the router uses to represent a specific entity from another subgraph. It contains a __typename property and values for the entity's primary key fields. In our case, the primary key field for both Host and Guest is id.

We'll return an entity representation for each the following resolvers in the monolith subgraph:

• Listing.host, which returns a Host type
• Booking.guest, which returns a Guest type
• Review.author, which returns a User type

To get started, open up the resolvers.js file in the monolith directory.

Listing.host

Let's find the Listing.host resolver. We'll remove the body of the function, where it currently calls the accountsAPI data source. We now want this resolver to return a representation of the Host entity.

Here we've destructured the parent argument (which is a Listing object) to retrieve the hostId property. This hostId is used as the value for the primary key field id.

Booking.guest

Let's do the same for the Booking.guest resolver. Find the resolver in the resolvers.js file and replace the body of the function so that it returns an object as the entity representation.

Similar to the Listing.host resolver, here we've destructured the parent argument (a Booking object) to retrieve the guestId property. This guestId is used as the value for the primary key field id.

Review.author

Finally, we have the Review.author resolver, which we'll handle slightly differently.

In the schema, the Review.author field returns a User interface, which is an abstract type. So the Review.author resolver will need to specify whether the returned type will be a Host or a Guest.

To determine the type, we'll need to look at business-domain-specific logic. We know that only guests can write reviews for listings and hosts. Similarly, only hosts can write reviews for guests. Knowing that, we can investigate the shape of a Review object and determine what property might be able to help us with that logic. Here's what a review looks like:

We can use the review's targetType property (which will either be LISTING, GUEST or HOST) to determine what the review author's type is. If a user is writing a review about a Listing or a Host, we can safely assume that user is a Guest!

Find the Review.author resolver in the resolvers.js file and replace it with the following:

And that's it for all the resolvers that return representations of entities!

Practice

Use this schema for the following code challenge:

Key takeaways

• Any subgraph that contributes fields to an entity needs to define a __resolveReference resolver function for that entity.
• An entity representation is an object that includes the entity's __typename and @key fields.
• An interface needs a __resolveType resolver.

Up next

Whew, that's it for resolvers! In the next lesson, we'll test that our changes are working locally before publishing the new accounts subgraph in GraphOS!