Check out a free preview of the full Server-Side GraphQL in Next.js course

The "Wrapping Up" Lesson is part of the full, Server-Side GraphQL in Next.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott wraps up the course by providing recommendations for using GraphQL going forward. He suggests figuring out where to install GraphQL, such as on the edge or as an API gateway, and choosing a framework like Apollo or GraphQL Yoga.


Transcript from the "Wrapping Up" Lesson

>> Scott Moss: Some of the things I want to talk about is just like what you can do going forward. First, figure out what layer you want to install GraphQL, right? So far, I'm gonna show you how to embed GraphQL into Azure API. But GraphQL can be installed in many different places, it can sit in between your client and your API, it can sit on your API, it can sit on the edge.

So you can run GraphQL on the edge on a CDN. There's so many layers on where you can put GraphQL. So if you are in the boat of yeah, we were thinking about GraphQL, but having to do a complete refactor of our entire backend sounds crazy, but we wanna use GraphQL.

Okay, make a server, pick whatever language you want and put GraphQL on that server. And have that sit in front of your actual backend and your client talks to that GraphQL layer and it treats it as like a API gateway. So that'd be like GraphQL as an API Gateway.

It's a great use case for using it on the edge or somewhere like that where it's hosted in multiple regions. That way you never have to configure your backend at all and really what your resolvers will look like, instead of talking directly to the database, your resolvers would make an HTTP request to your server, right?

That's what the data source would be, it'd be an HTTP request to your actual server that isn't using GraphQL, but the GraphQL is the one that's resolving it. So that's how you could do that. So yeah, figure out what you wanna do, where you wanna install it, and then I would say, figure out what framework you wanna use.

We've been using Apollo, this was really cool. This is probably my favorite one. So I would recommend checking this one out. I mean, it's all mostly the same. You give it a schema, you give it some resolvers, but I've always had better luck with the SWIFT, their API's, it's a lot cleaner.

So highly recommend checking that out. It's part of what's called the guild, it's either built by Apollo or some folks that used to work at Apollo. But it's like an organization who is just building cool shit for GraphQL is the best way I can describe it. So they have all different types of things that they built in here, each one of these modules, it has something to do with GraphQL.

So for instance, server side events, which if you don't know, is a way you can send a message from the server to a client, kinda like WebSockets, but just. Or it's like HTTP, but inverse, you're sending a request to the client. They have WebSockets. They have all different types of things.

They got custom scalars, you can do all different types of stuff. So highly recommend checking them out, if anybody's doing anything in GraphQL it's gonna be these folks. So give that a look. Some other things you want to check out are gonna be GraphQL Federation.
>> Scott Moss: So GraphQL Federation, the name has changed over and over and over.

It used to be called schema stitching. It used to be called so many things, but basically here's a good diagram. Imagine if you had many services, whether you made them or not, but they all use GraphQL. You can have one GraphQL schema that stitches them all together, and you can delegate which fields resolve to what schema, whether that schema is remote or local, it'll resolve to it.

And that way your client only has to talk to one. So it's really great for intercommunication with microservices if they all had GraphQL, which is the exact line that they talk about right here. So this is how you would do it without GraphQL, you have your client, gotta talk to this.

It also has to talk to this. It also has to talk to this, with GraphQL Federation, you move more into this. The client just talks to this one thing and this aggregates all of this data, and the communication layer here is all GraphQL. So I reccomend checking that out.

I guess they call it a supergraph now and schema federation and things like that, or a subgraph, I should say. Wait, no, there's a supergraph and a subgraph, I can't keep up with these terms. So I recommend checking that out, it's actually quite powerful. A lot of developer facing products now offer GraphQL schemas publicly and there's just more and more being added.

Like GitHub has a GraphQL API, that's the only one that I use because it's so much better. You can even go explore it, right? So from the GitHub GraphQL API, I'm pretty sure they have an explorer tool similar to the one that we just saw, here it is.

You can explore the GitHub API. You just gotta sign in and you can do all the things here the way that we've been doing. It looks a little different, but it's the same thing. So highly recommend checking out Federation stuff. And lastly, I recommend diving into, and maybe I'll create a course in this in the future, but more production stuff.

There are a lot of things that you really need to think about when going to production with GraphQL around like caching. Because if everything's a post request and the URL is entirely the same, that kinda breaks the traditional caching on the network layer that we're used to. If you think of like network layer caching, it's typically like a combination of this URL plus this verb, and it's typically GET requests.

You don't typically cache POST requests. That breaks, everything's the same URL, everything's the same verb. So how do you create a key? What is the cache digest key? How do you compose that? Is that created from the content of the query? How do you create a unique key, and things like that?

There are different tools out there. There's paid products, so figure out caching on the network layer, but also caching on the execution layer. Are you using Redis when you make these resolver calls, are you using something like data loader per request, indexing strategies. It really changes a lot, so what I just showed you is how you build an application.

But deploying it with a bunch of users and data, there's a lot that goes into it, that are as quite different than rest. So I recommend checking some of that stuff out. But if you haven't checked out the client side GraphQL course, please check that out. It works on the same app, but builds the client side that makes these queries.

They kinda go hand in hand if you wanna see the complete picture. So, yeah, other than that, thanks for coming.
>> Speaker 2: All right, here. [APPLAUSE]

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now