What is GraphQL

[00:00:00]
>> Scott Moss: First thing is, what is GraphQL? And why is it here? So here's the definition of GraphQL, and I'll basically tell you what I think it is and how it works. Graphkill is a powerful query language for APIs and a runtime for executing those queries with your data's type system.

[00:00:22]
Unlike REST, which uses predefined endpoints to access data, GraphQL allows clients to request exactly what they need and nothing more. ChatGPT helped me write that, by the way, cuz it sounds nothing like me. [LAUGH] What I think GraphQL is in the way I would describe it, it's basically like TypeScript for your API.

[00:00:46]
That's basically it. Who here has used TRPC or heard of it? Okay, TRPC is another way you can get typed queries. It's another way you can get typed data for your APIs. GraphQL what it is, it's basically a few things. There's a query language, which looks very similar to JSON and which you can use to describe the shape of your data.

[00:01:10]
And then there's a backend component that takes that query language, does exact type matching with it to make sure it fits the type so it does the craziest input validation you can think of on down to a property level. And then if that works, it then tries to resolve each one of those fields on your query that you asked for.

[00:01:33]
So that way, you can query highly relational data in any format that you want, whereas if you didn't have GraphQL, you could only query the relational data in whatever way that the person who built it back in allowed you to. Because they would have to write those queries, those database queries ahead of time, and it create the routes ahead of time and then give you the options for the query string ahead of time and like here are the rules you have to follow.

[00:02:00]
With GraphQL it's infinite. You can do whatever you want. So it's a different mental model when thinking about it, especially on the back end, but basically it's just a way for you to describe the data that you want and get it back exactly the way that you asked for it and guarantee type safety.

[00:02:19]
That's it So, that's GraphQL. So it's pretty cool. Created by Facebook a long time ago, and then they open sourced it. And so far it's been well used. You have big companies like Netflix using it. There are like startups who have billion dollar products that are tools just for GraphQL.

[00:02:38]
It's a huge ecosystem of people building products, companies using it, tons of open source. There's so many plugins and applications and tooling built around GraphQL. And one use case that I've learned with GraphQL that's quite useful in the client is for mobile, like mobile and GraphQL actually works very well.

[00:02:59]
Because for mobile you're very data constrained, you're network constrained. You really only wanna get the information that you need to put it on the screens. Anything more is can be quite expensive as far as like network requests. So GraphQL is great for that. And there's many other but that's actually a really great one.

[00:03:18]
I kind of already talked about some of the main advantages of rest and things like that. But really, the big advantage is you basically get type checking for free, you don't have to do the input validation. And on the Frontend, at least you get to describe what you want.

[00:03:35]
Whereas like with REST, you would have to have a conversation with the back end team like, okay, this is what I need on the frontend, can you make me a route that returns it exactly like this so I can use it on the frontend? You don't have to have that conversation anymore.

[00:03:48]
You just write the code for it and it just works. So you describe that shape within the constraints of the schema that you created. Some of the bigger differences are, REST is like a combination of a URL and a verb, basically, right? So if I have resources, like a user, a post, an article, whatever, for every one of those resources, I have a URL path for it, and then I have a verb that describes some crud action, a post for creating, Git for getting a patch, or a put for updating things like that.

[00:04:21]
So for every one resource, you might have, I don't know, five, six different routes just for one resource and REST. And then if you have many resources, those are a lot of routes you gotta manage. With GraphQL, it's just one URL the entire time, no matter what you wanna get, it's usually GraphQL.

[00:04:38]
And it's mostly always gonna be a post request. Pretty much guaranteed always gonna be a poster Chris. So that right there just makes it simpler in its own. You're only managing one URL or one route and you don't have to think about HTTP verbs. You don't have to think about any of those verbs or those methods because it's always gonna be a post.

[00:05:00]
So that already makes it simple. And then I would say, yeah, I could talk about the differences a lot in practicality, but high level, that's it, yeah, Mark.
>> Mark: What do you get with type safety when it comes to GraphQL?
>> Scott Moss: Yeah, so type safety is just a fancy word of saying when a client is sending some type of query to the back ends, let's say it's trying to create a user.

[00:05:27]
And to create a user, you have to supply an email and a password. Well, if you wrote a really good back enf, what you would do, you would first before you operate on your database, you would check the inputs that came from that client to make sure that there is an email there, you would make sure there is a password there.

[00:05:46]
If you had other validations that you put on the front end as far as like the length of the password, you would also check that on the back end. So it's like you're validating the input before you operate on the database, but you'd have to write that code yourself if you were doing something non-GraphQl.

[00:06:02]
Whereas with GraphQL, that's done for you for free. That type of validation is executed by the GraphQL server without you having to write the code for it before any of your logic runs to actually satisfy the query. So it basically just means it'll break if the query that you send up doesn't satisfy the type constraints of your GraphQL server.

[00:06:27]
Just the same way as if you would throw an error if someone sent up a payload that wasn't the exact shape or type that you need in order to resolve that request. It's just done for you for free. So that's what I mean by type safety and then to expand on that, you can generate type scripts from your graph QL and have type safety all the way down to your frontend code, and then it gets even crazier.

[00:06:52]
So that's what that means.
>> Speaker 3: When you say generate type script, I mean, you mean like for Frontend or explain that expansion?
>> Scott Moss: Yeah, for sure. So there are tools in GraphQL that will look at a GraphQL schema and then output a TypeScript file that has TypeScript types that you can then import into any other TypeScript file you want.

[00:07:14]
So in this case, maybe it's a React component, it's a file in which you're doing a query and then now, instead of just getting back a generic data property that is the result of your query. You can map that to an actual type that matches a server, right?

[00:07:28]
So like, you have
>> Speaker 3: Like object mapping.
>> Scott Moss: Yep, object mapping. Exactly, yeah. Because it's very common. TypeScript is great, but where it starts to fall apart is when you have to do network requests, because how would TypeScript know that this API returns this type of data, it just doesn't know.

[00:07:44]
So with GraphQL and then doing code generation, you can bring that all the way down to, literally the component level. So if you integrate with that tooling, yeah, you will have full type safety. So, and there's different ways to do that. TRPC solves this differently than GraphQL. GraphQL you have your cogeneration, TRPC you don't because it's Typescript and it uses TypeScript in the same repo to get it to work.

[00:08:08]
So there's different ways but yeah, there's cogent. We won't be doing code in this course because I felt like it's too TypeScript specific. And you have to know TypeScript to really understand it. So I didn't do it, but it's actually quite easy to do. Let's talk about the query language.

[00:08:22]
So GraphQL language, GraphQL. So let's talk about the foundations of it and then we'll kind of take a look at it. So one of the few things or one of the basic things about the Query language is something called a field. And again, I said, if you've written JSON before or you've written Javascript objects, you'll probably feel pretty familiar with GraphQL, is very similar to that.

[00:08:43]
So a field is exactly what it sounds like. It's like a field on an object. So you can specify which fields from what objects you need, and you'll only get back that field if it's there, depending on the schema and whether or not it's a non no field or it can be no or whatever.

[00:09:00]
But if you ask for it, that's what you'll get and nothing else. Nested objects, this is really cool because this has a lot to do with relational data. So if you had an author that had posts and you wanted to be able to get the posts for an author, you can start from the author object and nest into t the post object and ask for that data as well.

[00:09:24]
So you can do that in a way that is beneficial for the front end and not the other way around where the person writing the back end will have to predefine those queries ahead of time or they'll have to like create. Basically what will end up happening is people in the back end end up creating their own query language on a query string, and like, yeah, if you sent me this on a query string, this is how you can change how I do the relations.

[00:09:47]
But at that point, they're creating their own query language. So GraphQL is like trying to solve that. And then there's arguments. So you can pass different arguments to some of these fields and nested objects. That way you can do things like give me this author by this ID or given this user by this e-mail.

[00:10:02]
So there's a lot of argument passing. We'll discuss a lot of that as well. But those are the basic building blocks of doing a query from a request site. There's a little more we'll cover, but these are like the foundation, the basic stuff. So enough talking, let's get into it.

[00:10:19]
So here's what a graphical query looks like. Like I said, the kind of looks like an object, right? There's some slight differences here, you don't see like a key value, so it isn't like a field and then a value here, what this is describing is, imagine if we had a blog application where authors have posts.

[00:10:35]
This is saying, hey, I want to execute the author query, and I want to get the author with this ID. And then on the author object, I wanna get the name, I wanna get the email. And then I know authors have a list of posts. So what I wanna do is I wanna get the title and the content and the publish date for all the posts for this author.

[00:10:59]
So what I would get back is an object called author that has all these properties on it the exact same name, it will have an array of posts on it. And those objects will have these properties on it. Nothing more, nothing less. It'll be exactly this shape. So now you can write your UI in a predictable way.

[00:11:19]
You know it's always gonna come back this way. And the reason you know that is because GraphQL would break before it didn't come back this way. There's no way that it will respond to you with a successful request without it being this shape, because you can only send a query that matches the schema that was created.

[00:11:39]
So if you send something that wasn't possible, you'll get back an error. So if you didn't get back an error, you got back what you asked for. And that's the guarantee, that's the contract that type safety. So it's quite cool, but you would have to see the other side of it, which is a GraphQL schema, which is more backend related GraphQL, I'll cover that the backend course.

[00:11:59]
This course there is no GraphQL schema, you're just interacting with the GraphQL server you don't actually create the schemer. So you just have to imagine that there is scheme in the background.