What is GraphQL

[00:00:00]
>> Scott Moss: For this part, I'm just gonna kind of just talk about what is GraphQL, I also talk about this in the client side course. So if you watch that, it's gonna be kind of a recap for you. But basically, GraphQL, you can read the definition here of what it is.

[00:00:14]
The way I describe GraphQL is basically two parts. There is a query language, that's the QL part in graph. That query language is used to traverse any type of data source or many data sources in a very descriptive way. So that query language allows you to literally say, this is the shape of data that I want from the available data that I know about.

[00:00:37]
Make sure you return the data in this exact shape, so that's the query language. The other side of it is what we're making today is gonna be the part that satisfies that query language, that's gonna be the server component. So that server, its job is to architecture some way in which a client can query the given schema in any direction, any format, any shape that they want.

[00:01:01]
So there can be a pretty close to infinite amount of possibilities in which someone can query a GraphQL schema depending on how big the schema is. So the server's job is to make sure that all those possibilities can be fulfilled, which sounds quite difficult if you think about it from a perspective of making one rest route for one resource plus CRUD action.

[00:01:22]
That sounds like you'd be making a lot of routes and verbs, and things like that, but it's not architecture like that as you'll soon find out. So that's kind of how I describe GraphQL, and then just to tie it all together, there's a lot of type safety. So having that schema that tells the client what resources it can access, and then having the back end fulfill that query, there's type safety involved to ensure that the client can only ask for things in a certain type in which the schema created.

[00:01:51]
And if that contract is violated, the server will automatically error out, so if you don't satisfy the right type on the back end, if you ask for different things on the front end, you're gonna get errors. So that's not something unique to servers, but typically that's something you have to build yourself.

[00:02:10]
Every company I've ever worked at, where we were not using something like GraphQL, part of the stack was for sure validating input from a client. It's like, okay, here's the input, either we validate it from scratch or we have like, I've used things like runtime schemas like ZOD or things like that that will validate some user input.

[00:02:29]
Cuz you don't wanna trust a client, before we even interact with the database, which has another layer of validation with its own schema. So there's a lot of valid, and then on the front end for a form, you might have front end form validation. So there's three layers of validation you might have when it comes to accepting user input.

[00:02:44]
GraphQL takes care of the validating from the client to the back end, that's done for free given a schema, just like a database schema, if you try to violate that, the database should error out as well. If you have some primary key or some foreign key constraints on the SQL database, and you try to violate that on insert, then yeah, you're gonna have errors thrown from the database for free, you don't have to write that code.

[00:03:08]
You basically get that same experience but on the API layer with GraphQL, so it's quite effective as you'll soon find out. So created by Facebook, long time ago. And then since then, it's evolved into, I would say, it's pretty much a standard at this point when comparing it to other types of things out there like GRPC, obviously REST.

[00:03:31]
There's now TRPC, it's definitely up there. It's definitely in the conversation when it comes to what API should be built for something new. GraphQL is something that we thought about a lot at the company that I'm building and how we might use it because of just how useful it can be.

[00:03:49]
But now it's maintained by a large community. There are companies built on creating services, and plugins, and all different types of product for GraphQL developers, so when you see that, you know it's always a massive opportunity. But yeah, I'm pretty impressed with what GraphQL has done and how far along it's come.

[00:04:08]
So yeah, why would you use something like GraphQL over something like REST? I mean, we're gonna talk about that the entire course. But I would say, for me, especially on the back end, the biggest reason is that, well, the back end is so difficult the than the client side.

[00:04:23]
But I'd say some of the biggest benefits on the back end of why you would use GraphQL is that, you can tie into many different data sources, that aren't just like one database. So if you have microservice, if you integrate with Stripe, you integrate with this third party thing, you have different databases for whatever.

[00:04:39]
Yeah, obviously, you would write a bunch of business logic to tie all that stuff in and then surface that through whatever clients you want. But GraphQL just kind of makes that easy, because it's abstracted away from the data sources, but it creates a unified schema in which any client can query.

[00:04:55]
So if you have a mobile app that needs to get data, as far as you wanna get the user, you also wanna get the user subscription status, which comes from Stripe. You also wanna get something about the user that comes from their Google profile. Yes, you can curry all that individually, make a route for it, and then send it back to the client.

[00:05:16]
But you can also have GraphQL resolve those pieces of data individually and put them together for you in one single place, and one object type, and the client just gets that for free, and they don't even know about it. So, it's quite impressive when you can do things like that.

[00:05:32]
I think it also just, is a great way to organize an API as you soon find out that it's a framework really. I think for the most part, when it comes to developing APIs, yeah, we have things like Express and things like that, but you can still get pretty wild, I've never seen two express servers that look the same.

[00:05:51]
Even though they all use Express, they all look way different. Whereas, with GraphQL, it's like React, it's pretty much all gonna look the same, cuz if you don't satisfy the constraints of the framework, it won't let it start as you'll find out today. You really have to be pretty literal with the things that you make because it's so type heavy that it won't even start, so it gives you a little bit of security.

[00:06:12]
It also creates standardization around GraphQL API, so you can feel confident that you can go work on another one, even in another language. I've worked on GraphQL APIs and languages like Phoenix, I don't even know those languages, but yeah, I was able to work with GraphQL because it's abstracted so high from it that it doesn't matter.

[00:06:34]
Some of the bigger differences between GraphQL and REST, and we'll be talking about this throughout the course as well as we continue to go. But some of the bigger ones are, with REST there's a combination of a route and a verb for a resource. So if you wanna do CRUD, you might have a postrequestto/user.

[00:06:49]
You wanna get one user, it might be a getrequestto/user/userid, you wanna update one to put or a patch to user/id, right? So you're having all these routes for all these different resources, with all these different actions, not with GraphQL. GraphQL, there's just one URL, it's typically /GraphQL, and it's always pretty much gonna be a POST request.

[00:07:11]
And that's it, you only have one route, right? The actual part where you are asking for the information is part of the payload. Payload that you send up is what the server needs to figure out how to resolve your query, it's not part of the URL. So that's the biggest difference REST uses the URL to determine what it is you're trying to access, whereas GraphQL uses the body of the POST request to figure out what it is that you want after it validates it.

[00:07:40]
So, that's why you only need one URL.