Introduction to Next.js 13+, v2 Next.js Origins and Q&A

Transcript from the "Next.js Origins and Q&A" Lesson

[00:00:00]
>> The origins of Next.js. Next.js is a framework built on top of Reacts. You might be asking yourself, why do we need a framework on top of a framework? React is already a framework, what are we doing? Well, if you've ever used React, you know that it's not really a complete framework.

[00:00:15] I kind of think of it as like a view library, where it just gives you some really cool functions that are disguised as HTML looking things called JSX to build out a UI. But you still have to install your own router, you still have to install your own state management if you don't like hooks and things like that, there's like Redux and other state management lives.

[00:00:35] So it's not like the full thing, right, even though react supports server side rendering, It doesn't give it to you, you still got to set that up yourself, right? So it's like, eventually the community was like, why do we have to set this stuff up all the time?

[00:00:47] So Next.js K, Next.js is like I was gonna take all the conventions, and our own opinions, and we're gonna put them together in a framework on top of React. So you don't have to figure out what router you're gonna use and keeping up with API and then like what state management.

[00:01:00] And then how to render statically, or dynamically, or the server on the client will just give it all to you. And then they're like, well, why stop here? How about we figure out how to let people create API routes and things like that? Let's just go full stack.

[00:01:14] So it's a full stack framework built on top of React that basically bakes in a bunch of opinions and conventions. That the community is formed and their own opinions that they work with the people at the Google team, the React team to kind of figure out, let's just create a standard way of making a full stack React app.

[00:01:30] That way people don't have to do it from scratch. Because I mean, as you know, if you try to sit down and make a full stack app right now from scratch, I mean, you won't even get to the actual product code. Because you'll be so busy doing the architecture code for forever, like setting up a build system, doing optimizations, doing this.

[00:01:48] And then finally, you can like all right, now I can get to the product code after you set all this up. So Next.js is kind of solve that so you don't have to do it. So when should you use Next.js? Pretty much anytime you need to make an app with React, I would say it's because jit ust how flexible it is, it has different modes you can render in as we'll talk about.

[00:02:08] So it can handle small loads, big loads, it's a very flexible application. So I would say for the most part, I exclusively use Next.js for almost all my React projects. I would say the only ones I don't are obviously if I'm making a library that's being published on NPM, you don't use Next.js for that.

[00:02:26] It's only meant for apps, it's not meant for libraries, you wanna make a component live in Next.js. And then maybe just like some one-off small one-pager thing that I'm doing in React that I probably could have did in just Vanilla JavaScript. So why am I using React in the first place?

[00:02:39] Other than that, it's probably just Next.js. I don't know if I'll ever just use Vanilla React anymore in my opinion. Any questions on that? Yes,
>> Possibly off-topic, go as deep as you want or whatever, but I'm typically, when I think about React apps, I think of me there as kind of the hybrid approach where you have Django or rails or what have you.

[00:03:03] Same host shoots over the JavaScript and then just using you know surf tokens and then the kind of second version where it's just static JavaScript on like a CDN that speaks over JSON. In both cases, you'd say it's Next.js still offers a bunch of, it still offers substantial benefits, so for just key old React from the bottom up

[00:03:23]
>> Yeah, I think so, because Next.js uses, it leverages a CDN depending on where you deploy it. If you deploy it on Versace, or Net Laly,.or something like that, it leverages the CDN just the same way a static React app would. And those pages can be cash and things like that, and you have more control over them.

[00:03:37] So, and then you have the edge run time, which is really cool, so you get that benefit. And then obviously, you get the full stack, so you can have the APIs, but maybe it adds a little overhead. For instance, if you already have an API built out in Python, or Rails, or something, and now you gotta make another full stack.

[00:03:56] And Next.js and that API is talking to your already API and Rails or Python, maybe that extra network layer is maybe just a little overhead and people don't wanna manage it. So I can see that being an issue where it's like I don't really want to maintain another server even though it's serverless.

[00:04:12] Well, in that case you just don't even use the API routes in Next.js and you can just use the pages and the components and talk to your own API. It still works out, so I would say for the most cases, yes. Yeah, because what's gonna happen if you don't, especially on the team, there's one of two things is gonna happen.

[00:04:28] You're gonna have a meeting where some architectures or some senior folks on the team like, right, we gotta build some stuff around React, right? That's one thing if you're a good company. If you're not a good company, what's gonna happen is people are just gonna do it as they go, and then no one's gonna know what the hell's going on the app.

[00:04:43] They're like, what's going on here? And they're like, well, talk to that person. They don't work anymore, and it's like, okay. Don't touch that code is gonna be like a comment on top of the file. Don't touch this, because no one knows what it does, but it works.

[00:04:54] So this kind of avoids all that because you're gonna build your own framework, anyway. Yeah, Mark.
>> Could you give your thoughts on remix and potentially new stuff like Astro?
>> Yeah, so I actually don't have too much experience with remix other than just reading their documentation, unfortunately.

[00:05:12] So I don't have any opinions about it, I just know that they aim to deliver on some of the same things that Next.js does as far as like building out full stack applications. From what I understand, I think they're focused more on creating static applications from the folks that own that.

[00:05:29] But then again, I haven't really used it, so I can't really comment on that, but it seems promising, maybe I should check it out. But I tried to use it when it first came out, I think it was like invite paid only, or something like that. And I was like, I don't wanna do this, but I think it's open now, so I don't know, maybe I'll check it out.

[00:05:45] Astro is cool, I know a lot about Astro. So Astro is, I don't know what you would call it, I don't even really call it a framework. It's almost like a second architecture, it's like free architecture basically. It's like it's something that sits on top of your framework to allow you to create what's called like these dynamic islands or is that Apple's thing?

[00:06:10] I don't know, they call them islands to an Astro, I believe. That's also apples.
>> Do you call it Island.
>> Okay, I was like, wait, did I just get confused with Apples thing? Yeah, they call them Islands, which basically it's just an optimization on how you can render your components sending less JavaScript to the frontend, only streaming it when needed.

[00:06:26] And it can just wrap all your framework. So it's not so much that you would only use Astro over React or something like that as you would use it together. So it's just another tool to optimize things. There's always gonna be overlap, the frameworks themselves have their own optimization tools built in.

[00:06:45] The platforms you deploy to have their own optimization tools built in, and you have something Astro that has their own optimization tools built in. So you kind of got to figure out what's going to give you the best, it really isn't like one solution that's gonna work for everybody.

[00:06:58] It all really depends on where you deployed, who's on your team? What framework you're using? What version is it? Who has access to it? So they're all kind of shooting for the same thing, so that's my pain on that, yes.
>> Out of curiosity, would it be possible to kind of isolate or separate the frontend with the API side?

[00:07:20] For example, say you want like the API is used by many different services outside of just the frontend. And you wanna able to scale that, is that possible with Next.js? Or would you recommend using a different API entirely for that case?
>> Right, so the question was can you just forget about the frontend thing, just make a backend and scale that out, so you can use it with something else?

[00:07:38]
>> Yeah, so you have the frontend that exists with the Next app and the backend that you create with the Next.js application like API routes and stuff like that. Say that those get used much more by other services and the frontend still uses it, but say you wanna scale that up independently, is that a possibility?

[00:07:55]
>> Yeah, so in Next.js, those API handlers were meant to be serverless handlers. So technically, serverless scales as long as you throw money at it, so it'll go forever. So I guess, it really depends on where you deploy it. If you deploy to Versailles, what supports still service functions deployed to nullify which supports those service functions.

[00:08:15] Then yeah, it should theoretically just go as much as you need. I haven't seen problems with it. And it doesn't know or care that the frontend that it's bundled with is actually the client that's asking for the resources. So anything can hit it, whatever security policies you have as far as like IP addresses or whatever, it's totally fine, it shouldn't be an issue.

[00:08:34] So yeah, I don't think you're gonna have a problem with that. That's totally fine. Although, if you want it more granular, I don't know, API configuration is probably better to use like an API framework to do. Because building a serverless, It's definitely a lot different than not building a service, especially with the database you would have to pick.

[00:08:55] You can't pick a database that expects to be connected forever and pulling the connections, eventually you run out of connections. So you've got to either solve that or use a service database, which might change how you build your app. So there is a lot of decisions that go into working on a service app.

[00:09:11] Although there are a lot more options today than there were when I was making your service app like five years ago where there was not a service database and you had to figure it out. So yeah, that's the way I think about it.