Check out a free preview of the full REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course:
The "GraphQL & Express" 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:

GraphQL is seprate from the server and request-response cycle. So you need a server like Express to send and receive the data for your API. Express talks to the Node libraries that impliment GraphQL.

Get Unlimited Access Now

Transcript from the "GraphQL & Express" Lesson

[00:00:02]
>> Scott Moss: So GraphQL and Express. Why do we need both of them, right? Did I just show you some crazy stuff? Why do we need Express anymore? We still need Express, GraphQL doesn't do everything. GraphQL is not a server framework and, in fact, it's not a framework at all.

[00:00:16] It's just a Korean language, so we still need some infrastructure here. So let's talk about some benefits knowing that now we're all Express experts and we're learning GraphQL. Let's talk about some benefits here that we need to use them both together. So with GraphQL, we could continue to use our REST routes.

[00:00:31] You could totally do that. And like I said, there are so many ways to do that. You could use them side-by-side, on top of each other, and it's in so many ways you can actually use it. It depends on your business needs that the quick answer is however you want.

[00:00:43] You can do whatever you want because GraphQL does not replace res although it will eventually. It doesn't have to replace it. It's more of a layer that sits in front of it if you choose. GraphQL is something that site in front of your API, and then it doesn't care about what your API is.

[00:01:00] It doesn't make any inferences about what your API is, what your data layer is. It's just like, I'm gonna check the query before it comes in, and I'm going to check the data that you give me. If it doesn't match, I'm gonna complain. That's GraphQL. So it doesn't care where it's coming from.

[00:01:14] Doesn't matter How you're getting the data. That's it. So that means you can do whatever you want. Underneath it, before it, after it, it doesn't matter.
>> Scott Moss: You could benefit from middleware here. So if you wanna setup some global middleware for your entire GraphQL API, you can still benefit from that middleware there.

[00:01:33] But there are Better approaches to doing things for your GraphQL resolvers then setting up global middleware, or maybe you just want some global stuff, and in our case we probably will, but then there's like protecting like isolated resolvers which is a different approach than global middleware, but you could still benefit from it it's very very easy setup with GraphQL because I said yesterday Express is the go-to framework and there's pretty much a plugin, everybody makes a plugin for Express So you can be assured that there's probably a plug in Express with GraphQL and there is.

[00:02:03] There's so many of them. You benefit from error handling with Express so GraphQL depending on what server framework you use has its own error handling built in but you can also benefit from the error handling that you have with Express, kind of like we made yesterday, where the arrows bubble up and they do stuff like that.

[00:02:21] You can still benefit from that. Which is really cool. And then you could also reuse the Express libraries, which is the biggest benefit of using them both together. Express does a good job of packaging the requests that comes in, it gives you all the different information about it.

[00:02:33] The path, the query string, all the headers, it gives you access to all that cool stuff. We still want that in GraphQL, we still want to use that inside our resolvers. So I will say that's the biggest benefit of using GraphQL with Express and is that we can benefit from those libraries that Express gives us access to instead of our controllers.

[00:02:50] That request object is like powerful. And we want to be able to use that instead of GraphQL resolvers.