Follow-along: Connecting data with entities

15. Follow-along: Connecting data with entities

Goal: Implement the subgraph changes needed to resolve our dream query.

The dream query

query GetRecipeAndCookwareInformation {
  recipe(id: "rec3j49yFpY2uRNM1") {
    name
    description
    ingredients {
      text
    }
    instructions
    cookware {
      name
      description
      cleaningInstructions
    }
  }
}

Referencing an entity

Open up the schema.graphql file in the recipes subgraph.

Scroll down to find the Recipe type and add the new field at the end.

schema.graphql

type Recipe {
  # ... other Recipe fields
  "List of cookware used in the recipe"
  cookware: [Cookware]
}

Save your changes!
Which of the following scenarios happen after saving our changes?
Rover composes the supergraph and succeedsRover composes the supergraph and fails with a build errorRover automatically detects the schema changesRover composes the supergraph and stops running because of a build error
In the schema.graphql file, after the full Recipe type definition, add the Cookware type. Specifically, we're going to add a stub of the Cookware entity, which contains the minimum fields the recipes subgraph needs to reference it.
schema.graphql
type Cookware @key(fields: "name") {

}
Since the subgraph doesn't contribute any additional fields to the entity (we're only referencing the entity using its name field, not contributing fields to it!), we need to add one more thing. Inside the @key directive, add another argument for resolvable and set it to false.
schema.graphql
type Cookware @key(fields: "name", resolvable: false) {
name: String!
}
Save your changes.
Which of the following scenarios happen after saving our changes?
Rover automatically detects the schema changesRover composes the supergraph and succeedsRover composes the supergraph and fails with a build errorRover composes the supergraph and stops running because of a build error
Jump over back to the Sandbox tab which is connected to our locally-running router on http://localhost:4000 and run the dream query.
query GetRecipeAndCookwareInformation {
recipe(id: "rec3j49yFpY2uRNM1") {
name
description
ingredients {
text
}
instructions
cookware {
name
description
cleaningInstructions
}
}
}
What is true about the results of running the dream query?
The cookware field doesn't exist in the schema, resuling in an invalid GraphQL queryThe cookware field returns nullRecipe details such as name, description, ingredients and instructions are availableRover composes the supergraph and stops running because of a build error

Adding a resolver function for `cookware`

In the src/resolvers/Recipe.js file, add the following resolver function for the cookware field.

src/resolvers/Recipe.js

cookware(recipe, _, { dataSources }) {
  const cookwareNamesList = dataSources.recipesAPI.getRecipeCookware(recipe.id);
  if (!cookwareNamesList) return;

  return cookwareNamesList.map((c) => ({
    name: c,
  }));
},

What's happening here? Let's break it down.

First, the parameters of the resolver. We're using the first parameter parent (renamed as recipe) and the third parameter contextValue (destructured to access dataSources).

Next, inside the body of the function, we're using the dataSource method getRecipeCookware to retrieve a list of the recipe's cookware. This method was already implemented for us.

In the event that no cookware list was available for that recipe (it's possible that it just doesn't use any, or it is missing that data!), we'll return early.

Otherwise, we'll map over the list and for each item, return an object. This object is called an entity representation. It's what the router uses to represent a specific instance of an entity. A representation always includes the typename for that entity and the @key field for the specific instance.

The __typename field: This field exists on all GraphQL types automatically. It always returns the name of its containing type, as a string. For example, Cookware.__typename returns "Cookware".
The @key field: defines the entity's primary key, which uniquely identifies an instance of an entity. We know that the Cookware type's primary key is its name field.

So, going back to the last line in the Recipe.cookware resolver:

src/resolvers/Recipe.js

return cookwareNamesList.map((c) => ({
  name: c,
}));

In this case, we've omitted the __typename field because GraphQL takes care of returning that automatically. The cookwareNamesList only has a list of Strings, so we can't simply return that list, as-is. The map function takes care of transforming each item in the list into the shape the router is expecting.

Alright, we've got the code changes to back our schema changes! Jump back to Sandbox and run the query again.

query GetRecipeAndCookwareInformation {
  recipe(id: "rec3j49yFpY2uRNM1") {
    name
    description
    ingredients {
      text
    }
    instructions
    cookware {
      name
      description
      cleaningInstructions
    }
  }
}

Fantastic, we've got it! 🎉

Optional reading: How does the router use entities and the query plan to connect data from multiple subgraphs? Explore the details in Lesson 11: Entities and the query plan in the Voyage I: Federation from Day One course.

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.

Referencing an entity

Adding a resolver function for cookware

Share your questions and comments about this lesson

Adding a resolver function for `cookware`