WEBVTT 00:00.140 --> 00:05.450 In this video, you're going to learn what GraphQL is, what problems it's trying to solve. 00:05.450 --> 00:11.840 And by the end of this video, you will have your very own GraphQL API that you can build further on. 00:12.200 --> 00:20.420 GraphQL was developed internally by Facebook in 2012 and was released publicly in 2015. 00:21.030 --> 00:23.910 So why did Facebook create GraphQL? 00:23.940 --> 00:29.550 Did they just want to create something new for fun, or was there a specific problem they were trying 00:29.550 --> 00:30.210 to solve? 00:31.280 --> 00:37.730 GraphQL is a data query language, which means it allows us to make specific queries and only get the 00:37.730 --> 00:38.780 data we want. 00:38.810 --> 00:40.820 No more and no less. 00:41.480 --> 00:47.270 You can think of it pretty much as using SQL, but for the client side, such as on your mobile app 00:47.270 --> 00:48.410 or on your web app. 00:48.740 --> 00:55.160 This way you can make custom specific queries and get exactly the specific data you need for each client. 00:56.140 --> 01:03.610 Let's try and see how you could make a blog app inside of a rest API versus a GraphQL API. 01:05.120 --> 01:09.440 So let's say we want to build the profile page for our blog app. 01:09.530 --> 01:17.210 Profile page could have, for example, a username, let's call it Bob in this example and a picture 01:17.210 --> 01:25.730 of Bob, maybe a bio of Bob telling about his life and maybe the user's blog post, Bob's blog post, 01:25.730 --> 01:29.750 his updates, and then we have Bob's followers. 01:29.780 --> 01:33.560 Let's try and see how we could make this invest in rest. 01:33.590 --> 01:43.220 You define specific endpoints for different resources like this users slash ID and maybe you will get 01:43.220 --> 01:52.010 data such as this containing Bob's username, his profile picture URL, the bio of Bob and his followers. 01:53.270 --> 02:00.860 If you also wanted all of Bob's blog post, maybe you would go to another endpoint like this user's 02:00.860 --> 02:07.850 slash ID slash post, and this way you would get an array of all of Bob's blog post. 02:07.880 --> 02:14.750 Now, remember that Bob has a list of followers as well, and we would like to display these followers 02:14.750 --> 02:16.430 profile picture as well. 02:17.620 --> 02:23.890 Unfortunately, if we're really trying to make this follow restful guidelines as much as possible, 02:24.100 --> 02:30.760 we would have to go to a new endpoint on all the different users to get their profile pictures. 02:32.110 --> 02:39.190 And now, even though we only wanted the profile picture and the username from each endpoint, we also 02:39.190 --> 02:43.330 get each user's bio and even their followers also. 02:43.750 --> 02:44.620 Yikes. 02:45.400 --> 02:50.590 So this means we will be making a large amount of round trips to our API. 02:51.070 --> 02:57.280 Round trips means the motion of getting data from our server and going back to our server again, making 02:57.280 --> 03:01.120 new requests again based on the data we got last time. 03:02.350 --> 03:11.110 We could also have a user's bio on another endpoint or have followers on another endpoint, but we would 03:11.110 --> 03:16.190 still be making a lot of round trips every time we wanted to see a profile page. 03:16.210 --> 03:22.880 Then we would need to go to our endpoint for the bio and the endpoint to get the followers and so on. 03:23.210 --> 03:25.490 We'll still be making a lot of round trips. 03:26.810 --> 03:32.420 Round trips can take a lot of time and it can be slow and difficult to make a lot of round trips for 03:32.420 --> 03:36.770 the client, especially if the client has a bad network connection. 03:36.980 --> 03:41.390 This is why Facebook created GraphQL so people would are not so good. 03:41.390 --> 03:47.330 Internet connection could have a better chance of getting the data without making a lot of round trips. 03:47.360 --> 03:53.330 Now you might be thinking, well, why don't we just create an endpoint which has all the data we need 03:53.330 --> 03:54.800 for the profile page? 03:55.580 --> 03:57.170 And you could do that. 03:57.800 --> 04:03.440 The restful guidelines is saying basically you need to make an endpoint for every resource. 04:03.620 --> 04:09.230 In this case, we're making a specific endpoint for a page or a view. 04:09.350 --> 04:12.500 And the problem you have with that is this. 04:13.820 --> 04:17.600 Now let's say we create this endpoint for profile page. 04:17.810 --> 04:24.860 We can make one like slash pages, slash profile page, slash the user ID. 04:25.730 --> 04:30.440 Now, when we go to this endpoint with Bob's user ID, we see this. 04:30.620 --> 04:37.790 We see Bob's username, his followers, the bio, his profile picture, the post. 04:38.180 --> 04:42.380 So basically we're getting all the data we need to show on this profile page. 04:42.620 --> 04:43.720 Problem solved. 04:43.730 --> 04:45.650 No round trips, right. 04:46.640 --> 04:51.380 So unfortunately, we have a problem now. 04:52.760 --> 04:59.790 What if you have a mobile client and you don't want to show as much data as you do on the web client? 05:00.270 --> 05:08.160 Now you need to create a new endpoint or you'll be using the same endpoint and you'll be getting more 05:08.160 --> 05:09.450 data than you need. 05:09.720 --> 05:20.460 So either you make another endpoint for a mobile app, for a web app, maybe even a console client. 05:20.490 --> 05:21.360 Who knows? 05:21.960 --> 05:29.280 Or you follow the restful guidelines to the tick and you end up with a ton of round trips. 05:31.930 --> 05:34.780 Now, what if there's a better way? 05:36.130 --> 05:39.970 This is why Facebook built GraphQL. 05:40.960 --> 05:50.140 They wanted to build a smart API, which could fetch the data exactly as the client wanted dynamically 05:50.140 --> 05:52.480 for each different client. 05:53.260 --> 05:57.580 Now let's see how GraphQL can solve this problem for us. 05:57.910 --> 06:01.490 Let's see how our GraphQL query for this could look like. 06:01.510 --> 06:09.850 So in this case, we have a query called Get User and we ask to get the field username profile, picture 06:09.850 --> 06:14.020 bio and the post and the followers. 06:14.140 --> 06:21.520 And inside each of these fields we have sub fields with the title and content for the post, and likewise 06:21.520 --> 06:22.390 for the followers. 06:22.390 --> 06:24.940 We have the username and profile picture. 06:25.210 --> 06:27.730 And this is how the response would look like. 06:27.940 --> 06:31.550 So as you can see, we get exactly the data we want. 06:31.940 --> 06:38.930 But now let's see how it would look like if we have a mobile client and maybe we don't want to show 06:38.930 --> 06:41.210 the content for each post. 06:41.690 --> 06:46.130 So this is how our request would look like on the mobile client. 06:48.040 --> 06:52.450 As you can see, we removed the content from the post field. 06:52.480 --> 06:57.100 Now we just get the same response but without the post content. 06:58.090 --> 07:00.250 This is the beauty of GraphQL. 07:00.340 --> 07:04.590 You can get exactly the data you need, no more and no less. 07:04.600 --> 07:07.130 And without making any round trips. 07:07.590 --> 07:13.030 You can adapt your queries as much as you want on various different clients you may have. 07:13.420 --> 07:20.920 Now, if you know rest well, you might also know that rest has something called query variables, which 07:20.920 --> 07:24.910 means you can make a bit more custom requests to your endpoints. 07:24.940 --> 07:34.180 For example, you could have a query variable saying Show post content to false or show byrow to false. 07:35.200 --> 07:37.240 And that works well. 07:37.270 --> 07:43.870 Maybe you could use that to change up things for your mobile client or change some things for your web 07:43.870 --> 07:44.620 client. 07:44.950 --> 07:52.040 The problem with these types of query parameters is that you can end up with URLs that looks like this. 07:52.670 --> 07:55.160 I'm not even going to speak this out. 07:55.490 --> 07:57.920 This is not even the worst I've seen. 07:57.920 --> 08:07.850 I've seen much worse in production rest APIs where you basically have to read a manual to figure out 08:07.850 --> 08:13.670 what you have to pass in of parameters and variables inside of your query. 08:14.000 --> 08:21.680 Sometimes people even convert these types of get requests into a post request because there are so many 08:21.680 --> 08:25.040 variables you need to pass in to get the content you want. 08:25.790 --> 08:32.030 And what's worse is that rest is not self-documenting, which means that it's up to rest developer to 08:32.240 --> 08:38.360 document how the API works, or you have to document how the rest API works. 08:39.260 --> 08:42.440 And that can get pretty hairy sometimes. 08:43.490 --> 08:51.350 Thankfully, GraphQL is self-documenting, which means that you can explore the API, look at what fields 08:51.350 --> 08:56.540 you can request and what queries you can make, and you can see it very easily. 08:58.100 --> 09:04.430 I hope you've gotten interested in the problems that GraphQL can solve by now, and maybe you want to 09:04.430 --> 09:07.310 get started building your own GraphQL server right away. 09:07.310 --> 09:12.370 Now in the next ten minutes, we're going to build our very own GraphQL server. 09:12.380 --> 09:16.310 It's going to be a basic, simple movie library. 09:18.230 --> 09:24.050 In this section, we are going to build a basic GraphQL API for a movie database. 09:24.290 --> 09:31.580 It's going to be a GraphQL API containing info about movies, their actors, directors and so on. 09:31.970 --> 09:35.630 In the final project we will be able to create movies. 09:35.630 --> 09:41.420 Read our current list of movies, update info about the movies, and of course delete the movies. 09:41.840 --> 09:47.990 So in the end of this project, we will have learned how to build a basic Crud app with GraphQL. 09:48.560 --> 09:55.970 Later on, we will see how we can connect to a database like MongoDB and have our very own movie database. 09:55.970 --> 10:02.150 But for now we will just create a basic GraphQL API to get a taste of how GraphQL is like. 10:03.100 --> 10:08.130 To get you started, you will need to have NodeJS and Visual Studio code installed. 10:08.140 --> 10:14.590 Please go to nodejs.org and install the latest version of Node. 10:14.980 --> 10:18.220 If you do not have node or installed already that is. 10:19.390 --> 10:25.060 In this course I will be using Visual Studio code, but if you prefer to use another editor, you are 10:25.090 --> 10:26.740 of course free to do that. 10:27.040 --> 10:33.340 First thing I will do is I will go into my integrated terminal in Visual Studio code and create a new 10:33.340 --> 10:35.020 folder for our project. 10:35.050 --> 10:37.450 Let's call it movies. 10:37.450 --> 10:46.570 So I will type make Dear GraphQL movies and let's go into our newly created folder in Visual Studio 10:46.570 --> 10:47.230 code. 11:04.380 --> 11:11.190 Now let's create a index.js file where we will be creating our GraphQL API. 11:13.580 --> 11:16.850 And let's go inside of our integrated terminal again. 11:16.850 --> 11:20.180 And this time we will type npm init. 11:20.210 --> 11:21.200 Dash dash. 11:21.200 --> 11:21.830 Yes. 11:22.310 --> 11:27.350 In this case we will be using Apollo server and GraphQL node packages. 11:54.570 --> 11:56.920 Now let's get on to the coding part. 11:56.940 --> 12:00.870 So let's first import Apollo Server and gql. 12:01.680 --> 12:06.030 So const Curly Brace, Apollo Server. 12:06.150 --> 12:10.020 Comma Chikuwa Curly brace. 12:10.320 --> 12:13.890 And we require that from the Apollo server package. 12:15.920 --> 12:25.080 Now Apollo Server lets us create a GraphQL API really fast, which is using Apollo server 2.0 and Gql 12:25.130 --> 12:28.880 is to create our GraphQL type definitions. 12:29.720 --> 12:35.240 I will explain soon what type definition is and how we create one and so on and what they mean. 12:35.750 --> 12:41.420 But for now, let's just create our sample data collection which we will be exposing through this GraphQL 12:41.420 --> 12:42.350 API. 12:42.980 --> 12:45.500 It's going to be a really basic sample data. 12:45.500 --> 12:49.880 We will be creating a we're going to be creating a array of movies. 12:49.880 --> 13:00.710 So we have Const movies, Square bracket, and inside here we have an object, which is a movie containing 13:00.710 --> 13:04.550 a title Terminator two Judgment Day. 13:05.540 --> 13:12.980 The movie has a director, of course, which is James Cameron in this case, and an array of actors. 13:13.010 --> 13:17.880 In this case, we just have one actor we put in Arnold Schwarzenegger. 13:23.230 --> 13:32.200 Then we go on to the next movie, which is Alien, and it has director Ridley Scott and the actors. 13:32.200 --> 13:35.290 In this case we put in Sigourney Weaver. 13:36.250 --> 13:43.210 Okay, so that's our sample database we're going to exposing in through this GraphQL API. 13:44.080 --> 13:48.220 Now let's create our type definitions for GraphQL. 13:49.420 --> 13:54.040 So we put in const Typedefs. 13:54.070 --> 13:55.630 Notice the capital D. 13:55.660 --> 13:57.340 That's important later on. 13:57.580 --> 14:02.590 And we put in Gql and Backticks. 14:02.620 --> 14:03.970 Notice the Backticks. 14:03.970 --> 14:05.320 That's important. 14:05.740 --> 14:10.250 And inside the Backticks, we type our types in. 14:10.270 --> 14:13.690 In this case, it's type of a movie. 14:13.840 --> 14:19.600 And the movie has a title, a director and actress. 14:20.290 --> 14:23.410 So title is a string. 14:23.410 --> 14:27.370 In this case, it's a scalar type string. 14:27.430 --> 14:36.130 So GraphQL is a strongly typed language, which means we can write the scalar types for each of these 14:36.730 --> 14:38.560 int results we get. 14:39.940 --> 14:45.500 And movie itself is a scalar object which we can define ourselves. 14:45.520 --> 14:51.730 You can also define your own custom scalar types, but most of the time you can get along fine with 14:51.730 --> 14:55.660 the core scalar types that GraphQL has. 14:56.140 --> 15:06.670 The example of core scalar types that GraphQL has is int, float, string, boolean and ID. 15:07.900 --> 15:12.910 But remember, if these are not enough for you, you can always create your own custom scalar types 15:12.910 --> 15:19.840 or import even third party custom scalar types if you want to use other people's types. 15:22.150 --> 15:22.540 Okay. 15:22.540 --> 15:31.130 So and then we have a director which is also a string, and we have lastly the actors. 15:31.150 --> 15:38.200 So the actors is a bit more special because that is an array of the object type actor. 15:38.650 --> 15:45.340 So we need to write our own object type beneath, which is a type we call actor. 15:45.460 --> 15:51.880 And it's going to be really simple because it just contains a name, which is the scalar type string, 15:52.570 --> 15:55.210 and that's pretty much it. 15:55.240 --> 16:00.010 Now we just need the final type, which is a special type in GraphQL. 16:00.040 --> 16:07.960 It's called Query, and this is where we can have our root queries we can make in the GraphQL API, 16:07.990 --> 16:11.510 which means it's the queries we can start out with. 16:11.530 --> 16:15.280 So I will show you later on so you can see how this works. 16:15.280 --> 16:24.050 But for now we will write in movies and it's going to return an array of the object type movie, just 16:24.050 --> 16:30.160 like we did in the movie where we have actors that returns an object type array of actor. 16:30.170 --> 16:36.980 We have the root query called movies, which returns an object type array of movie. 16:38.880 --> 16:41.340 So that was our type definition. 16:41.340 --> 16:43.590 That was pretty simple for now. 16:44.160 --> 16:51.960 It's a lot of new concepts you have to take in, but hopefully as we keep building on this project and 16:51.960 --> 16:54.090 you keep practicing, you will get it. 16:55.560 --> 16:57.720 Um, that's all there is to that. 16:57.840 --> 17:00.120 Now, um, let's see. 17:00.120 --> 17:01.670 We need to write our solvers. 17:01.680 --> 17:06.270 Now, we basically did 80% of our GraphQL API now. 17:06.420 --> 17:08.520 Now we need to write our servers. 17:08.520 --> 17:16.650 So resolvers define how we get our data in the queries while the type definitions define what is our 17:16.650 --> 17:19.560 data, how is it related to each other? 17:20.010 --> 17:26.700 So we write const resolvers and this is an object which contains lots of properties. 17:26.700 --> 17:33.840 In this case we write query property, which is the root query we can make, and that again has a different 17:33.840 --> 17:36.990 properties, which is the queries we can make. 17:37.980 --> 17:44.680 In this case we have the movies and this is basically a function which returns our data. 17:45.580 --> 17:54.190 Now in a normal API, we will of course have calls to, for example, a database here or even other 17:54.190 --> 18:01.960 rest APIs or other APIs you have, and you would make the calls and fetch the data in here. 18:01.960 --> 18:08.980 But in our case we have just a simple movies array, so we just return that movies array and GraphQL 18:08.980 --> 18:16.480 is automatically going to do all the filtering we need to do for getting the specific fields. 18:16.750 --> 18:23.620 And you will see later on when we fetch with the when we, uh, fiddle around with the client how this 18:23.620 --> 18:24.310 works. 18:24.610 --> 18:32.380 So we have the movies, which is just a basic function that returns the movies array. 18:33.070 --> 18:37.990 Now let's get on to actually creating our server and starting it. 18:38.620 --> 18:42.610 Const server, new Apollo Server. 18:42.880 --> 18:46.900 We pass in our type definitions and our resolvers. 18:47.740 --> 18:56.680 Now we can start the server, we write server listened and then we can do a console log where we show 18:56.680 --> 18:59.500 our URL that the server is starting on. 19:14.880 --> 19:16.200 Okay, great. 19:16.230 --> 19:18.780 Now let's start the server. 19:18.810 --> 19:25.560 We can now run Node Index.js inside of the console and we will see the server running. 19:26.220 --> 19:31.570 Now, when the server is starting, you can see inside of the console the URL that the server is on. 19:31.590 --> 19:38.520 In this case, for me it's localhost port 4000 and we can go inside here. 19:39.960 --> 19:45.300 Now when you click on the address in here, you will be taken to something which is called the GraphQL 19:45.330 --> 19:46.590 Playground. 19:46.800 --> 19:52.080 It's a newer version of the GraphQL exploration client. 19:52.080 --> 19:59.610 You can say before we had something called GraphQL, its older version, but it still is being used 19:59.610 --> 19:59.910 a lot. 19:59.910 --> 20:07.500 But GraphQL Playground, for example, has Http headers and built in that you can set, which is going 20:07.500 --> 20:11.160 to be useful, useful later on for projects you're doing. 20:12.060 --> 20:18.860 So and you can say GraphQL Playground is what Postman is to rest. 20:18.870 --> 20:26.910 So if you mess around with rest, you probably use Postman before to explore an API to find out what 20:26.910 --> 20:33.120 kind of queries you need to make to get the data you want inside of your clients, such as your React 20:33.120 --> 20:35.610 client or your mobile client and so on. 20:36.970 --> 20:41.050 So let's see how our data looks inside of GraphQL playground. 20:42.070 --> 20:47.590 Okay, so inside of GraphQL Playground, you can make the queries. 20:47.590 --> 20:50.170 You can explore the API that you have. 20:50.890 --> 20:53.910 And you can even explore the schema. 20:53.920 --> 20:57.530 We have the type definition schema we defined before. 20:57.550 --> 21:04.600 So if I click schema over here on the right side, I can explore the queries, I can make the root queries 21:04.600 --> 21:08.860 we see here, which is movies that's returning an array of movie. 21:09.400 --> 21:16.630 And we click here, we can see the type of movie it has a title, director and actress. 21:16.810 --> 21:22.210 And again, if we click on actors, we can see what type is an actor. 21:22.210 --> 21:26.800 So actor is a type containing a name, which is a string. 21:27.370 --> 21:31.120 So that's how you can explore the API one way. 21:31.120 --> 21:37.180 Another way is to simply type in here and you can get auto completion running. 21:37.960 --> 21:44.410 So if I type the curly braces in here, we can see there's auto completion coming up with the root queries 21:44.410 --> 21:45.160 I can make. 21:45.160 --> 21:53.090 In this case, we have the movies query I can make and if I type enter, select it and make a space 21:53.090 --> 22:00.680 and then I type control space, I can have another root query, but that's not what I want. 22:00.680 --> 22:09.080 I want to get the subfields of movies so I press a curly brace again and now I can select the sub fields 22:09.080 --> 22:10.250 of the movies. 22:10.250 --> 22:13.880 So in this case, title director and actors. 22:14.300 --> 22:16.520 So let's select the title. 22:17.090 --> 22:19.580 And we see there's no red squiggly lines. 22:19.580 --> 22:20.750 So I can make the query. 22:20.750 --> 22:26.960 Now I can press the play button over here or press control, enter as the shortcut. 22:27.860 --> 22:31.760 And now we get the data we want or we want. 22:31.760 --> 22:38.150 In this case, for example, if we have a mobile API or a mobile client and we just want to get the 22:38.150 --> 22:39.500 title of each movie. 22:40.310 --> 22:47.180 So here we have the data which contains the movies array with the title. 22:48.640 --> 22:56.770 You can also press Prettify over here to format the query you want more nicely so we can build further 22:56.770 --> 22:57.340 on it. 22:57.340 --> 23:04.030 And let's say we also have a web client and on this web client we also want to display the director 23:04.480 --> 23:12.220 so we can press just show us the director by pressing control space and you can get the auto completion 23:12.220 --> 23:15.700 press enter and then you can press control Enter. 23:16.740 --> 23:20.490 And now you also see the director inside of the results here. 23:20.880 --> 23:31.500 So let's say we also want to see the actors so we press enter again and press control space and select 23:31.500 --> 23:32.850 the actors. 23:33.300 --> 23:41.880 Now, since actors is an object type and it can't be shown as it is just like that, you also need to 23:41.880 --> 23:44.310 have a selection of sub fields. 23:44.550 --> 23:50.550 So you need to make another curly bracket in here and you need to pass in another sub field. 23:50.550 --> 23:56.850 So in this case we only have one sub field, which is the name of the type string like so. 23:56.850 --> 24:04.050 And now we can fire off this query again and we see all of the actors inside of the movies, or at least 24:04.050 --> 24:04.890 one of them. 24:05.460 --> 24:10.260 Um, and again, we can press prettify over here to prettify our query. 24:12.390 --> 24:14.400 So that was pretty much it. 24:14.400 --> 24:21.720 That is how you make a GraphQL API in ten minutes or so and you start exploring it in four minutes. 24:22.380 --> 24:31.260 So in the next sections, I would like to show how we can connect to a real database such as MongoDB 24:31.350 --> 24:33.450 or create movies. 24:33.480 --> 24:39.810 You can also create objects, of course, through GraphQL, just like you can create objects in rest 24:40.020 --> 24:45.870 or delete movies or get a longer list or add more data to the movies. 24:45.870 --> 24:51.090 Basically build further on to this API that we built in just these ten minutes ago.