What is a Graph?

Andrew Mead
A free video tutorial from Andrew Mead
A Full-stack Developer & Teacher
4.7 instructor rating • 4 courses • 359,424 students

Lecture description

In this lesson, you’re going to learn how to think in graphs. This will set us up to work with a GraphQL API in the next lesson.

Learn more from the full course

The Modern GraphQL Bootcamp (with Node.js and Apollo)

Learn how to build GraphQL applications using Node.js. Includes Prisma v1, authentication, Apollo Client, and more!

23:24:42 of on-demand video • Updated November 2020

  • Learn and master GraphQL by building real-world Node applications.
  • Use Prisma v1 to store and access data from a production database.
  • Use Apollo Client to communicate with GraphQL from your web app.
  • Learn how to deploy and test your GraphQL applications.
  • Test your skills and gain confidence by completing more than 80 coding challenges.
  • Get access to a free 110-page PDF guide with lecture notes, code samples, and documentation links.
English [Auto] To kick off this section, I want to answer a very important question, which is what is a graph? It's right in the name graph. Well, and it's something that we're going to have to learn a little bit about before we can continue on. Now, when we're talking about a graph in graph, well, we're not talking about the kind of graphs or charts we would create in a tool like Excel to plot some points over time when we talk about a graph in graph. Well, we're talking about a way to think about all of our application data and how that data relates to one another. And we're going to move through a quick visualization in just a second to show how this would look in a real world application. Before we continue on, you might have noticed this is a presentation video. I avoid using presentations like this as much as possible in my courses. I use them very sparingly only when I truly believe it is the best way to get information across. And in this video, I think a presentation is the best way to explain what a graph is. Don't worry, though, like all my courses, 99 percent of this class is me and you in the text ed writing code. But going through the process of exploring what a graph is, is going to give us a solid foundation for actually writing code very soon. For this visualization, let's use the example of a blogging application. So we have users that are going to sign up and log in to the application. Once they're logged in, they're going to be able to create and publish posts. And once a post is published, other users are going to be able to read that post and add comments on to it. So as I described in English, there are three main things that we're going to be storing for this application. We're going to be storing users. We're going to be storing posts, and we're going to be storing comments in graphical. These are known as types and types are things that we define when creating our APIs, something we'll be doing in just a few videos. So in this case, we have a user type, we have a post type and we have a comment type, all things that we define. And when we define the types that make up our applications, we also define the fields associated with each type, the individual pieces of data we want to store. So in the case of a user, what do we want to track? Well, that's really up to us to figure out what makes sense for all of our types. We're going to have a unique ID to uniquely identify that user or that post or that comment. In this case, let's say it's the string one. And after the ID, it's really up to us to choose what we want to track. So for a user, maybe we want to track their name under a name field will store that as a string. And an example would be my name, the string Andrew Mead. We could also choose to track other things like their age. And for me that would be the number 27. Now each type we create is going to have its own set of fields. So all users are going to have an ID, a name and an age. All posts are going to have a completely different set of fields for a post. We're still going to have an ID, something to uniquely identify that post. But then we're going to track things specific to the post, like the posts title, the posts body and whether or not the Post has been published. So in this case, I have added a title for my post. The body is completely empty and this post is not published. So we're storing the boolean value false for unpublished as opposed to the boolean value. True saying the Post is indeed published. The last type that we're going to be working with in this example is the comment. So a comment is also going to have an ID in this case, 99. And for comments, the only thing we're going to keep track of is the comment text. And in this case, we have a very nice comment, just saying thanks for the post. So for this visualization, we've created three types user post and comment, each with their own custom set of fields. All of this should seem familiar because it's exactly how we would represent our data with any standard database out there. If I was working with an actual database, I would have a user's table, a post table and a comments table where all of the individual fields were individual columns on those tables. If I was working with a NQ Eskild database like Mongo DB, I would likely have a users collection, a post collection and a comments collection where all of these fields were fields on the individual documents created. Remember that graphical doesn't care what backend you're using. So in the end of the day, it might be an actual database or it might be a no Ezekial database. Either way is perfectly fine. Now, aside from each of our types having their own discrete set of values, we also have relationships between our types. So, for example, if a user creates a post, that post is associated with the user. So we would have a relationship like the following where a user has many posts via the posts property. Now to save space here, this user just has a single post, but we could easily imagine they have zero posts or they have 42 different posts. Now, if a user has many posts, that means a post also belongs to a user. So each post is associated with a user via the author property on that post. Now, there's relationships between our other types as well, for example, the comment to post relationship a post can have many comments and maybe we access those via the comments property and they comment is associated with a post via something like the post property. Last up comment to user. A user can have many comments. They've written on all sorts of posts. Well, a comment always belongs to an individual user and we might have that association via the comment author property. So in the end of the day, our graph could look a little bit like this, where we have type's user posts and comment. They have discrete fields and they also have associations between various types. In the end of the day, this is how we're going to be thinking about and representing our data in Graph QoL. That's where we're going to stop for this one. Now that we know the basics of what a graph looks like in graph, well, we're actually ready to move on to the next video where we're actually going to put our hands on the keyboard and write some graphical code. We're going to figure out how we can query from a real graphical API. I'm excited to get to that. So let's go ahead and jump right in to the next one.