Updating our schema

2. Updating our schema

Overview

Our track detail page needs more data than a homepage card. We'll update the schema to match the mockup before we touch resolvers or the client.

In this lesson, we will:

Review the Track page mockup and identify new fields
Extend the Track type with description, numberOfViews, and modules
Create a Module type for units of teaching within a track

👀 Reviewing our design

Let's start with the mockup of the Track page our design team provided us with. Here we'll need to display more information about a track than what's contained in a card on the homepage.

A mockup of the Track page showing a track thumbnail, title, and data about its modules

In addition to what we had in our card, a track needs to have:

a description
the number of views
the list of modules included in that track

For each module, we want:

the title
the length

✍️ Updating the schema

Let's open up the schema.graphql file in the server/src folder.

We'll start by updating the Track type. We'll add the description (which is a String) and the numberOfViews (an integer, Int). Oh, and let's not forget to give our fields nice comments!

Add the following fields inside our schema's Track type:

server/src/schema.graphql

"The track's full description, which may include Markdown"
description: String
"The number of times this track has been viewed"
numberOfViews: Int

Next, what should we do about our track's modules?

Putting our business glasses on, it looks reasonable to assume that a module should be a standalone type: a single track might include any number of modules, and one module might be part of multiple tracks. So, we'll create a separate Module type.

A module has an id, which is required. It also has a title, which is a required String and a length, which is an Int. We'll add comments for this type and its fields as well.

Add the following to our schema:

server/src/schema.graphql

"A single unit of teaching. Multiple modules compose a track"
type Module {
  id: ID!
  "The title of the module"
  title: String!
  "The module's length, in minutes"
  length: Int
}

Now that we have our Module type, let's go back to our Track type.

We know that a Track can have multiple modules, so let's add a field to Track called modules, which returns an array of Module objects. This array can't be null so we add an exclamation point at the end, and the entries in the array can't be null either, so we add another exclamation point after Module.

Add the following field to our schema's Track type:

server/src/schema.graphql

"The ordered list of modules that make up this track"
modules: [Module!]!

Code review

type Query {
  "Fetch a list of tracks for the homepage grid"
  tracksForHome: [Track!]!
}
"Educational modules teaching a specific topic"
type Track {
  "The unique identifier for the track"
  id: ID!
  "The title of the track"
  title: String!
  "The track's primary author"
  author: Author!
  "The URL of the track's illustration, used in the track card and track detail page"
  thumbnail: String
  "The track's approximate length to complete, in minutes"
  length: Int
  "The number of modules contained in this track"
  modulesCount: Int
  "The track's full description, which may include Markdown"
  description: String
  "The number of times this track has been viewed"
  numberOfViews: Int
  "The ordered list of modules that make up this track"
  modules: [Module!]!
}
"A single unit of teaching. Multiple modules compose a track"
type Module {
  "The unique identifier for the module"
  id: ID!
  "The title of the module"
  title: String!
  "The module's length, in minutes"
  length: Int
}
"An author of a track or module"
type Author {
  "The unique identifier for the author"
  id: ID!
  "The author's first and last name"
  name: String!
  "The URL of the author's profile picture"
  photo: String
}

Practice

Which of these are reasons to create a separate Module type?

A list field can only contain object types.A module can belong to more than one track.The types in our schema must correspond exactly to objects returned by our REST API.A track can contain any number of different modules.

Given this schema field: missions: [Mission!], which of the following statement is true:

The list's items can't be nullThe list's values never changeThe list can't be nullThe list must contain at least one value

Up next

Perfect, we have our types updated according to our client's needs. Are we done with the schema definition? Not quite! For the moment, we only have a tracksForHome query that returns all of the tracks at once.

In the next lesson, we'll update our schema to retrieve a specific track, using arguments.

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.