2. Feature data requirements

💾 Data!

Before we get our hands dirty, we need to answer one important question: What data do we need to build our feature?

Let's take a look at the mockup our design team sketched for us. This is what the homepage should look like: a nice clean card grid.

A mockup of the app, showing a grid of learning track cards

Before you continue, take a moment to review the mockup and determine which information we'll probably need to populate a single card.


Based on the mockup, it looks like we'll need the following information for each learning track:

  • Title
  • Thumbnail image
  • Length (estimated duration)
  • Module count
  • Author name
  • Author picture
A doodle identifying the pieces of data for each track card

The graph

Looking at the list above, we can start to think about our app's data as a collection of objects (such as learning tracks and authors) and relationships between objects (such as each learning track having an author).

Now, if we think of each object as a node and each relationship as an edge between two nodes, we can think of our entire data model as a graph of nodes and edges. This is called our application's graph.

Here's an incomplete representation of our application's graph, based entirely on our mockup's data requirements:

A doodle of a graph, consisting of nodes with relationships to other nodes

Which of these accurately describes a graph?

Our job in the next couple lessons is to define this graph structure using a schema.