Build a Fullstack Music App with Next.js Middleware Q&A

Transcript from the "Middleware Q&A" Lesson

[00:00:00]
>> So if you're making say a server with node and express, there's the concept of middleware a lot, at least which is used. And that you could just deploy on Heroku, right, cuz that's running node. But for this idea of middleware, we're talking about edge, which I'm assuming it will deployed in a very specific way if it's in production.

[00:00:18] So is there limited options for deploying in next js applications?
>> So very good question. Yeah, so next js is created by the people who make Vercel, which is their own hosting provider. They have their own architecture. So yeah, I think that's their play, right, is to create all these awesome tools that integrate with their framework, that their platform supports out of the box.

[00:00:39] But they've also done a really good job of making sure that that architecture works outside their platform, too. So I haven't investigated how you might go about getting their edge functions to work outside of Vercel. But I would imagine, one, it would require you to deploy to a place that even had it in the first place.

[00:00:59] Heroku doesn't have it. Even though they use AWS, which does have it, Heroku just hasn't done it yet. I know they're in talks of doing x functions and lambda functions, but they just haven't done it yet. So you probably couldn't do it there. But I would pretty sure that if you deploy this to AWS yourself, you should have access to it.

[00:01:17] Because I know if you deploy just a regular next js without the middleware, you have access to the edge functions that next js has in AWS without going to Vercel. So I would imagine you do have that, but you want just the best compatibility, just deploy to Vercel and yeah, they have really good deployment.

[00:01:36] So it's not that big of a deal, but yeah, very great question.
>> If you see that the 404 pages don't redirect, is there a way to redirect that as well?
>> Yeah, 404 pages don't redirect. Is there a way to redirect for 404? There are so many ways to redirect.

[00:01:53] It depends on when and where you wanna redirect. Do you wanna redirect before your app runs? Do you wanna redirect during server time? Do you wanna redirect during client time? I just made those two things up. But yeah, so if you wanna redirect before your app is executed, then you would just write another middleware, right?

[00:02:13] You would write another middleware based off some rules. Who knows what it is? Maybe you have an array just like I have here with all your routes. And if none of the incoming request matches those routes, you can redirect to wherever you want or set the response to 404, however you wanna do it.

[00:02:31] If you wanna redirect on the server, we haven't gotten into server side functions yet, inside of the components, we will soon you can redirect in there. The third option is you can wait till your component loads up on the client, and you can use the use router to redirect from there as well, yes.

[00:02:48]
>> Is there any relation of middleware functions to angular interceptors?
>> That's a really, damn, some geez, in there, okay. Angular interceptors, I haven't heard that in a long time [LAUGH]. Okay, question, yeah, is there relationship to these middleware functions to interceptors? In concept, they're very similar. They both intercept a request, and they manipulate that request or they check something, and they either continue on to another middleware or they stop.

[00:03:20] The only difference is for the angular interceptors, those happen during runtime in a JavaScript context on your browser, right. So they're intercepting typically JSON requests. If you're making an API call, you can make an interception on the way out and you can intercept it on the way coming back from the server.

[00:03:38] Whereas this is actually happening on the network layer. So this is not happening in the browser like an angular interceptor would, this is happening on a CDN somewhere. So it's already left the browser, the request is headed to the server. Before it gets to the server, it stops on the edge of the CDN which is whatever is closest to you.

[00:03:58] So if you're in San Francisco, then the closest one might be in Oregon somewhere. It'll stop there and be like, actually, I gotta check your token before I send you over to this server to render this homepage for you. Let me see what you got. So it's a little different because it happened somewhere else, but the concept is the same.

[00:04:17] And the benefit of that is that because it's happening on the network layer, you get the benefit of still being SEO friendly. So think about making a middleware on the network that checks someone's IP address, looks that up in the table to see that this is Coca-Cola or this is some big company.

[00:04:35] And then, getting the html document from the source, changing out some headers on the page to say, hi Coca-Cola and then sending it back. So now Coca-Cola sees a custom page just for them based off their IP address and it's still SEO friendly, right. So you can do that on the edge, where if you did that on the server, it wouldn't be SEO friendly.

[00:04:53] If you did that on the client, it obviously would not be SEO friendly, so different things like that.