Hasty Treat - Upgrading Next.js Syntax Site

Welcome to syntax pnpm episode 271.

This Monday, hasty treat, we're gonna be talking about how we upgraded our syntax Scott f m site to use Next JS latest versions for everything, including Node v two.

We have, the site's gone through some evolution, and there's been some big changes to it with the help of the next team. And, I think there's a lot of lessons to be learned here. This is a true tales from developer land. So my name is Scott Tolinski, and I'm a developer from Denver, Colorado.

And that little laugh you just heard with me JS always is the Wes Bos. How you doing, Wes? 'Sup, everybody? What's up? What's up? What's up? Sup? And this is gonna be a good one for those of you who work at Next. Js or those of you who are curious.

This episode is sponsored by one of our sponsors here we love over here at Syntax, and that's LogRocket. And Node LogRocket is the perfect place for you to get a session replay of any errors or bugs happen.

Now typically what happens is user creates a bug somehow. The user just creates the bug. Right? You didn't you didn't code the bug. The user made made the bug. And, and that and the site breaks, and you don't know what happened. You just maybe get an error log or maybe you get a notification saying that something broke. But with LogRocket, you get a video. It's like being a detective and actually being able to see the crime happen. You can scrub through it, get your network activity, get the console logs and errors. It's like, not only get the video there, that you also get wiretaps and all that stuff. Look at this. I'm really stretching this metaphor, and I think it works really well. So you're you're gonna wanna head over to logrock.comforward/ syntax, and you're gonna get 14 days for free when you sign up. And there's an on premise or a cloud version of LogRocket.

So the everybody's needs seem to be taken care of here. So check it out at logrocket.comforward/syntax.

Alright. Let's get into it. So the Syntax website, let's say some history,

of the Syntax website, was built, I don't know, probably 3 three and a half years ago whenever we started this podcast. By Wes. I minimally contributed. I'm I'm really sorry for that. But you just, like, pulled it up in one day. You're like, oh, by the way, I'm on the site. It's

done. Yeah. It's just built a quick little website in Next. Js, and it was hosted on Zite Node, which is now called it's now it's just called the Vercel, which is so when we refer to Vercel, we mean both the company as well as the the hosting of it. And at the time, it was a custom node server that would take in the request and then pass it along to Next. Js itself. And we'll talk about why we needed a custom node server in just a second. But, that that was what it was. And the ZiteNow version 1 point o has has been gone for, like, a year and a half. And we just I just left it running on that because I didn't feel like updating anything. So, the other day, we woke up. It had stopped deploying because I ignored all of the emails that it was going to stop deploying. And, it sort of just dropped in our lap that we we could no longer redeploy the website, and there was an error on the website.

So luckily, huge thanks to Tim and Lewis who work on the Vercel and Next. Js core team. They both work at Vercel as well. They've seen this coming for, like, a year and had updated our site to use the latest Next. Js, which has no need for a custom server and would also be able to deploy to Node too. So actually, this is a question I get a lot. A lot of people are like, why can't you host Node apps on Node too, which is now called Vercel? They don't allow you to run, like, long or or constantly running node processes.

They only run serverless processes, which spin up when a person visits a website and spin down. So if you wanna host like a a node server that is always running, then you can't do that on on Vercel anymore. And that's why a lot of my my courses don't work on on Vercel anymore. So, like, our options were either just move it to a, like, a DigitalOcean or Heroku or something like that or just just update the website.

Why did we have a custom node server for the website when it seems so simple? Like, why not just, do that? And we'll all we'll also talk about, like, why not Gatsby or SAP or something like that for the site, near the Deno? So there was 3 things that we we use the custom server for. The first one was there's an API behind the syntax website. And the reason why that's there is, 1, because I use it in some of my tutorials. If you wanna pull in a list of something and render it out, it's nice to have something that's not your same old, like, static data JS well as, like, I've used APIs in the past, and then they change, and then the tutorials at a date. So, like, it's great to have an API that you can use that you actually have control over. So there's that. And then I also pull in the latest Syntax podcast into my own website and that's done via the API.

Second, we need on demand page builds. So you might say like, well, why not just Gatsby? Because we need to be able to release the new podcast episode at 9 AM on Monday and Wednesdays.

So when somebody visits the website, every single time that someone visits the website, it pulls a list of podcasts that should be available at that given millisecond and then renders them out and ships them to the browser just like any server rendered website would do, any PHP or whatever website would do normally.

And then the third reason we had a custom server was because of custom routing. So previously on Next. Js, the only way to do dynamic URLs was to pass the dynamic bit as a query param. So if that was the case, you'd go to syntax.fmforward/showquestionmarkepisodequals Wes and title equals, and then it would be the the URL encoded version of the title, and that just looks ugly. We wanted, like, nice custom URLs, which is forward slash show forward slash 261 forward slash hasty treat whatever whatever.

So those 3 things are now a thing in Next. Js. So we were able to upgrade. I'll I'll go over them. So the first one was the API. Now we use API routes. That's something built into Next. Js, which is really cool because you can just go into your pages directory and create a folder called API.

And then those endpoints will be deployed serverlessly.

But you can also use all of the packages and

helper functions and everything like have have you used API routes in Next. Js before, Scott? I have a course on it. Yeah. Oh, beautiful. Yeah. So definitely yeah. So, I mean, it really and and not only that, but I I've the Sapper version is, like, basically the same thing. So I I've had a lot of experience both within how Next does it as well as how Sapper does it. And it's really just basically giving you access to a, a server side route, and you can do anything on that route, really.

Yeah. Whether or not it's loading ESLint Apollo API or whatever. Yeah.

Yeah. It's great, and you don't have to, like, provision any servers or API keys or, like, a lot of these serverless things, they make you have your own package JSON. Oh, yeah. And then if you wanna share like a like a helper function between 2 server serverless functions, then you have to, like, publish that as a package.

And Next. Js just bundles it all for you.

It doesn't matter where you put your stuff. It will figure it out and bundle it up for you, which is the Wes. It's probably the the best server less experience I've had so far after trying a whole bunch of them. Just wait until you try Sapper.

Beautiful. And and Wes is so annoyed with me. I mean, I did this in the last episode, and, I did this on Twitter when we were talking about it. I was just joking, but I I think they handle it just a tiny little bit better. I think there are improvements that could be could be made. I don't know. It's good. Yeah. At least you're not talking about TypeScript all day long. It's nice to have a bit of a change. Yeah. And I Node. I know. I know. I know. I know.

Yes. Sorry about this. Whatever. So next one was on demand page build. So when a new episode comes out, then the page has to be refreshed, and you will see the new episode. Right? So if this was Gatsby or any other static statically generated site, you'd have to regen the entire website, like, at 9 o'clock, and then it would be like 9:10 by the time it hits your website. Or you do it, like, maybe try do it before, but it that's kind of annoying.

So that is something that initially wasn't possible because Tim, who who refactored the site, refactored it to use Next. Js's new static site generation, which is really cool. So Next. Js now has the ability to statically generate pages, and you can opt in to that on a page by page basis, which is like, I think, Wes of both worlds. You can have server rendered when you need it and then static generated when you need it. And he opted to make the entire site static generated, which is great, except for the the one part that we need to be dynamic, which is we need the whole thing to be regenerated when there's a new episode out. Right? And then you have to, like, set a cron job up, and that's kind of annoying. You Node? If we release 1 at a different time. What we really need

is a Libsyn Sapper version. No. No. I'm not. This is the 1st time I'm not gonna say sapper.

What we really need is a Libsyn, like a hook, something that just fires up that we could just say, hey. Just fire off a a message when this is published on Libsyn, and, like, come on. That would be the best way to solve any of these problems. It might even exist. Wes I didn't even look into that, so that might exist. But I I think the way that they they did it is pretty cool. So it's still statically generated, meaning that you go to syntax. Fm,

that is like blazing fast because there's a static HTML page.

But there's a flag that they added, and it's called unstable regen where this is not part of Next. Js yet, but we're we're I guess we're kind of beta testing it. So the way that it works is that when somebody visits the website, you can set how many seconds you want it to regen after, and they just set it to 1, meaning that every single time someone visits the website in the background, it's going to regenerate the next version. So at the very least, somebody visits our website at 9 o'clock and they don't see the new episode, but then the person that comes and visits it after them see it because it regens after every single time, which is kinda cool because it's still statically generated.

But it's also it's also we don't have to redeploy the entire build because it it does it for you. Yeah. That seems like a best of both worlds kind of situation. Yeah. Yeah.

I I so far, it's it's been good. There was a couple little bumps, but, we figured them all out. And then finally, the third thing, custom routing, that is now a thing in Next. Js. So you can do sort of like URL matching Mhmm. With the square brackets in the thing.

So it's awesome. It's it's nice and fast. It's super fast to load, super fast to build. Like, the whole Vercel build and deploy was done in, like, 3 minutes or something like that, which is much faster than my Gatsby website. And, I guess I have more images on my Gatsby website. So that's not really a fair comparison, but it is pretty nice and fast, and the deploy is is nice and fast as well. One, like, little pnpm point I have is that Vercel seems to have a lockdown on the API routes, meaning that, like, if you wanna use Next. Js API routes, you can't just deploy that thing anywhere because they've got some secret sauce on their own hosting platform.

And if that was the case, then you'd have to, I'm not really sure what you'd have to do. You'd have to, like, remap API folder to your own server. There's there's some people that are working on solution. Yeah. But that's kind of like a like, I get it. That's their business. You gotta have something.

Yeah. If we if we wanted to deploy this thing to, like, DigitalOcean, I don't know if that would just work, because there's some secret sauce in Versailles to make the a API routes work.

Yeah. And I just think it's interesting, and it's funny because our our site has always been a perfect use case for static generation, but there are those challenges involved. So I think this all seems like a nice little, nice little fix, and it's really amazing of the next team to come in and help us out like this.

Yeah. Yeah. Very much appreciate that because they didn't have to like, it's also like it's not very it's less complicated than it was before because they took out all of the custom logic on the server and just replaced it with pages. Right? It's just pages and a lib folder. And they they took all the the functions that we had written before, and and they all just work, which is pretty nifty. Yeah. So, big fan. So the the other Wes is, like, why not use Gatsby? We've mentioned this before, but we'll, we'll address it. Gatsby was not as popular when I built the website, so that's probably why. But then we also have the additional challenge of having to regenerate it at 9 o'clock to release the Node.

Whereas this just happens automatically And we can deploy it whenever we want, as well as the API routes where Wes could totally do the API routes with, like, a Netlify functions, but that is not something that's built into Gatsby yet. So you you you, again, you have to think about where am I hosting this thing in order to make the serverless function part work.

Yeah. And then the last 1 you hear says, why not Sapper? And it's so funny because when I made that little tweet, I wasn't honestly seeing that we should rewrite the site in Sapper because that we'd have to rewrite all the components, all the player. You'd rewrite all the CSS. You had no. I'm I'm just joking. You know? I I don't mean to be that, like, sort of, why don't you just completely rewrite the whole thing from the ground up? I we both have businesses to run. We both have way better things to do than that. So, by all means, that was intended to be as a joke. I do like Sapper, though. I will say that. Yeah. So

would my question is, would Sapper be able to do all of these things? I think the answer is yes. Everything except for maybe not the,

on demand page build SSG. I'm not sure what the answer to that is. I haven't looked into that kind of thing before. But, yeah, Sapper does static generation. It does server side. It does page server Node routes like Next. Js does. So it does all that stuff very well. So it basically does everything Next. Js does except for this. So yeah. Yeah. I think it could do it fine. Cool. Somebody also tweeted me the other day. They just, like, ported the entire website to Gatsby, and they redesigned it. It was really slick looking. And I was on my phone, and now I can't find the tweet. Like, it was it was one of those things. Like, if sometimes if I don't reply,

it's because I, like, see it when I'm like Oh, yeah. Me too. Trying to put my head about that. I should be paying attention to my kids, and then I just never and then I'm I it's gone. And I don't know where that is. So if you are the person that ported the entire website to Gatsby, send us Tolinski again because that, a, is really cool and, b, the design was really sick because the design of the syntax website is okay.

But now that we have 200 and 61 episodes, it could it could use like a maybe a rethink as to how to scroll the episodes a little bit nicer. We're using position sticky a lot, but as the data changes, maybe the design needs to change too. You know what I've been thinking about? I mean, we haven't really announced anything like this because there's nothing really to announce. But this is episode

271, and we're recording this about a a a month back, may maybe maybe a month and a half back. Right? Well so we're we're actually banking a couple of episodes. We're doing a lot of recording right Node, and Wes and I will be taking a tiny little bit of a break, but you will not experience a break because we're recording so many episodes ahead of time. Right? So Yeah. On September 2nd, we're effectively starting season 2 of syntax. You could call call it that.

There's not gonna be a ton of changes or anything, so don't be worried about that. But maybe that's a dice all time for, maybe a tiny little visual update or visual refresh to the site. Maybe we can take some that time off to brainstorm some things and and write some code.

I don't know. I'm excited. Maybe we can get some new new bumpers, some new audio stuff. The bumpers. Yeah. Gotta have some bumpers. I I I do want to get a bumper with, turbo instead of El Toro Loco. As much as I love El Toro Loco, I can't help but feeling it's a tad bit insensitive. I don't know.

That's just my thoughts on it.

Cool. Alright. I think that's it for today. Thank you so much for tuning in, and we'll catch you on Wednesday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows, and don't forget to subscribe in your podcast player or drop a review if you like this show.