What is a Graph?

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 GraphQL. 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 GraphQL, 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 GraphQL, 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% of this class is me and you in the text editor 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 onto 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 GraphQL. These are known as types and types are things that we define when creating our GraphQL 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. We'll 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 Post's title The Post's 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 SQL database, I would have a users 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 NoSQL database like MongoDB, I would likely have a user's collection, a post collection and a comments collection where all of these fields were fields on the individual documents created. Remember that GraphQL doesn't care what backend you're using. So in the end of the day it might be an SQL database or it might be a NoSQL 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. UST 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 a 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, while 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 types, user post 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 GraphQL. That's where we're going to stop for this one. Now that we know the basics of what a graph looks like in GraphQL, 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 GraphQL code. We're going to figure out how we can query from a real GraphQL API. I'm excited to get to that. So let's go ahead and jump right in to the next one.