This course has been updated! We now recommend you take the API Design in Node.js, v3 course.

Check out a free preview of the full REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course:
The "GraphQL vs REST" Lesson is part of the full, REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course featured in this preview video. Here's what you'd learn in this lesson:

A comparison of REST and GraphQL. GraphQL is typed and is a dynamic single endpoint. With REST you have to predefine the data and endpoints individually

Get Unlimited Access Now

Transcript from the "GraphQL vs REST" Lesson

>> Scott Moss: So here's just some points on GraphQL versus REST, this is not a complete list. And these are mostly just my opinions, some of them are facts. GraphQL, on the left, we have one route, it's not based on HTTP verbs. So you won't be posting, deleting, getting, putting, you won't be doing any of that.

[00:00:22] It's mostly just post, sometimes get, depending on what client you're using, but it's usually just post or get. And obviously there's an options request if you're doing course, but that has nothing to do with GraphQL. Strict data typing, so like I said, you can think of it as like TypeScript for your API.

[00:00:37] So everything has to go through that schema and it's going to be checked by that schema. And, if it doesn't match, that's not even going to invoke your resolvers. Interactive docs, as you'll see soon, right out of the box, you get interactive docs. Because everything is strictly typed, we can do introspection on the schema, which allows us to see every single type inside our API.

[00:00:59] Which allows us to visualize it and have documentation that we can explore freely. Works well with the component architecture, and in fact, that's where GraphQL came from. When Facebook created it, they had component architecture with their React Apps and their React Native Apps. And whatever they had, and REST was just falling apart.

[00:01:17] So they decided to build something with the perspective of a component architecture, and that's where GraphQL came from. Advanced data resolving, so like I said, controllers yesterday are like, I'm going to resolve something for this request. Resolvers are like, I'm going to resolve something for the shape of this field.

[00:01:35] For this one thing, and then a combination of those resolvers ends up being the response from your server. Now, the word graph in GraphQL signifies something, it's because you're kind of building a pseudo Graph API. It's not a real Graph API unless you're using something like Relay or something.

[00:01:53] But basically, it allows you to make associations on the fly, right? So if you think about a relational database, you set up those relations ahead of time. Right, you're like, this thing relates to this, I'm going to have a table, I'm going to do populate. You set that up ahead of time, where GraphQL, you can do that at runtime.

[00:02:08] It depends on, as long as everything eventually resolves to something. You can query it however you want to query it, and those queries might not be the way you define them. Like in REST, you predefine how something is going to respond to something. In GraphQL, it can respond dynamically as long as you set the resolvers up to resolve to something eventually.

[00:02:28] That sounds confusing but basically all it means is you have a tree. And if you resolve every single leaf, then anybody can query your tree and eventually get some type of shape. And that shape that you query might be different than the shape that I query. But at the end of the day, everything resolved down to the lowest point of a leaf of a tree, and that's basically what GraphQL is.

[00:02:49] Whereas REST is like, you have to predefine those branches and that's it, you can't explore and get dynamic with it. So REST has many routes, it's based on HTTP verbs. I did put one benefit of REST here, this is a little advanced, but it's cacheable on a network level.

[00:03:04] GraphQL, one of the downsides, it's not cacheable on a network level. And what I mean by that is, so normally for us, you would probably cache something on a CDN level, or something like that. You could do that with GraphQL, but you'd probably just have a lot of cache misses.

[00:03:19] Because, if you think about REST, REST, when it uses caches on a network level, it's probably using the URL as a digest, right? To do the caching, well, in GraphQL, because you only have one URL, the digest is probably the query that you're setting up. Depending on if it's a post or not, so now you've got to digest on that, and most CDMs don't support that.

[00:03:37] Some CDMs do support digesting on the body and stuff like that. But even then, somebody can ask for the exact same thing with one thing slightly different and then it will be a cache miss. So, to take advantage of GraphQL caching, you'll probably do application-level caching. A lot of Reddits, a lot of Memcached, a lot of request time caching, so there's other limitations.

[00:03:57] But taking advantage of the network-level caching is something that GraphQL doesn't really have a good story for yet.