Wrapping Up

[00:00:00]
>> Okay, well, then I'll talk about some things that I think you should look into next to further your learning. So the number one thing, obviously, next js docs. It's amazing. It's actually quite good. It's very thorough. And if you were to read through most of this, you will find out that we probably only covered 30, 40% of it.

[00:00:17]
There's so much more in here, it's ridiculous. But a lot of it has to do with performance and alternative ways of doing the same thing and configuration. So, one thing that we did not talk about too much was, let me see. We did not talk about some of the other advanced routing things you can do.

[00:00:36]
So we didn't talk about, where is it at, parallel routes, which uses the @ sign. My goodness, yeah, we didn't talk about that because it's actually quite advanced and there's really not a good use case for it, other than some really advanced thing. But if you wanna know more about that, you can look into it.

[00:00:52]
I'll probably cover it in the full stack course, actually, I think I will. We also did not talk about intercepting routes, which works very well with parallel routes. And this is your ability to add this stuff into your file names. If the dots drove you crazy before, these are 100% gonna drive you crazy.

[00:01:11]
It's actually quite difficult to reason about, took me a week to actually understand what this was. I actually had to go look at the pull requests in which the person suggested this feature on the team to understand the philosophy behind why this was a thing, and only then did I understand it.

[00:01:29]
So, but at face value, I did not understand this. So it was quite difficult. So I didn't wanna talk about that today. [LAUGH] Yeah, and there's some other stuff in here as well, but those are some of the big ones. Other things I didn't talk about, optimization things like images.

[00:01:46]
I didn't really talk about this because, I mean, at the end of the day, the image component works like a regular image component. But then you could do all this other crazy stuff with it for optimizations, but I didn't feel it was necessary until you needed it. There's some fun stuff here.

[00:02:01]
Lazy loading is pretty big, so you can dynamically load in other components, which is actually pretty cool. This works great for client side things in which you don't want to show and therefore download JavaScript for things that aren't on the page yet. So if you have some type of component that doesn't get shown until some interaction happens, you can lazily import that and then render it when the interaction happens.

[00:02:24]
Which will delay the download of that JavaScript and that component showing up, which should make your loads faster. So it's actually really cool to be able to something like that. We didn't talk about, let me see, is there something in data fetch? Yeah, we didn't talk about caching and fetching too much.

[00:02:40]
I mean, I did, but I didn't get into the examples of it. You should check it out. It's really cool. It's very fascinating. I think the entire framework is built on this concept, so they're putting a lot of money into that. Those are probably the big ones. There's still some some smaller ones in there, but I think for the most part those are probably the big ones.

[00:03:01]
You can look into the compiler. You can look at the turbo pack if you want, but it's probably not necessary. There's a crazy amount of configuration you can do in the next config, I mean, I'm still scrolling, it's a lot. So, [LAUGH] you can do a lot in the next.config, and that's mostly because you're interacting with the compiler at that point.

[00:03:19]
And if it's Webpack, which if I look at the output of, where did it go? Yeah, it looks like it's Webpack by default now still. And I know Webpack has a million options you can do. So you can check that out. And then here are the other built-in functions that we didn't talk about.

[00:03:35]
I didn't talk about redirects, not found, use path name, use router, use selected layout segment. There's a lot of functions in here that next js has packaged that we did not talk about. So, you can look at draft mode. Don't get me started about draft mode, it's actually quite amazing, but you need a CMS in order to actually [LAUGH] understand it.

[00:03:56]
We're not doing CMSs today. So it's really cool. They have a something for everything most likely, so I highly recommend checking it out. Other than that, I do recommend just taking this logic, and I'm a true believer the best way of learning something is just sitting down. Deciding on building something that's probably, I wouldn't say too far out of your skill set, but far enough to where you couldn't just sit down and do it without referencing anything, and then go make that.

[00:04:23]
And then once you make that, enhance that thing, go add more features to it. Maybe add a better design to it. Go on dribble.com and find a design and implement that design. That's actually how I started learning apps. I would just go and Dribble, I go find designs that I really liked, and I'm like, all right, I'm gonna turn that to an app.

[00:04:41]
And then that's what I did cuz I was not a designer. I didn't have a designer friend, so I just found designs and did that, and I made sure it was just right outside my skill level to where I knew I had to look things up and learn.

[00:04:51]
You don't wanna do something that's too easy. So I think once you do that two or three times with next js, this will just become so familiar to you that you'll understand it and and, yeah, you won't really be looking things up too much. So that's my opinion with pretty much anything as an engineer learning something, and the sooner you get those reps in, the sooner you can be proficient with it.

[00:05:12]
So those are my recommendations.
>> In terms of authentication authorization, is there a next prescribed way of doing that? Is that something more depends on?
>> I'm very opinionated about that. I used to be in the boat of I'm just gonna roll my own auth, and there's something called NextAuth.js out there.

[00:05:34]
If you're in a boat of rolling your own auth, just use this. Just don't use anything else but this. It's really good. I'm now in the other boat where I don't wanna roll my own auth. I don't wanna waste time doing the same thing. I realize every time I roll my own auth, it's the same auth.

[00:05:49]
I got to the point where I would make it from scratch, it would be the same way every time. And then I find a library and I'm like, this saves me so much time. Then I use the library and the config will be the same thing every time.

[00:05:59]
And I was like, okay, I'm just copying and pasting the config from every repo that I've ever made. And then I was like, I don't really wanna do this anymore, because it's the same thing every time. It's auth, and I'm not a auth expert. I'm not a security expert.

[00:06:12]
So now I prefer to use services, and actually found a really good service that we'll be using in a full stack course that takes two seconds and it's the best thing I've ever seen in my life. So if I heard the question, right, it sounds like they're asking if I have a page that fetches data.

[00:06:29]
But the way that it fetches data is from a route on an API that I created. If that's the case, there won't be any data fetching in the browser, that would all happen on the server that this function gets executed. And then because this is serverless, that would call your API server function, which spins up and makes that call through whatever private network this got deployed to.

[00:06:53]
So there shouldn't be any browser communication there, that should still just be server to server communication. I mean at that point it's just treating it like a third party API, and the only benefit you would get is if however this got deployed, they were in the same VPC.

[00:07:07]
And other than that, it's usually the same, so you shouldn't have a problem there as far as going through the public internet, depending on how it got deployed. Now, if you also did some API call inside this component, well, then you couldn't do any of this because that would make it a client component and therefore you couldn't do this.

[00:07:28]
So you could only, you can only do either, or, you couldn't make an API call in here and a use effect. And do browser site API calls, but also get data on the server for this because you can only do one or the other. You can't do both.

[00:07:41]
So I don't think you'll actually run into that problem.
>> It's kind of a loaded question.
>> Okay.
>> Is Next.js optimal for enterprise apps?
>> So the first company I've ever started was a consultancy. It was a dev shop for enterprise companies. All I did for two years, almost three years, we're helping enterprise companies get off of, I don't know, Django or WordPress or something like that, on to something that was enterprise.

[00:08:09]
Most of them chose Angular too, some of them chose Vue, some of them chose React. I can tell you without a doubt that enterprise ready. First of all, I think it really comes down to the infrastructure, where you deploy this, can you deploy it to somewhere that's enterprise ready?

[00:08:25]
Yes, Vercel is enterprise ready, Netlify is enterprise ready. So that answers that problem. Two, it's a front end app that leverages technologies that have already been proven to be enterprise ready, like serverless functions. So in that case, absolutely. Then the third thing that might be more important is when it comes to organizing things and patterns, I would say it's probably more enterprise ready than something like vanilla React, where you kind of just do whatever the hell you want, however you want.

[00:08:54]
And whoever is a team leader is gonna come up with how things are done. At least in the Next.js it's closer to what you might get with Angular, maybe more opinionated than Angular. Whereas there's a bunch of adventures you have to follow so you don't have to teach or enforce those.

[00:09:08]
You either do them or it doesn't work, and there's no in-between. So I would say it is enterprise ready for sure, seeing how it's mostly just code that executes on enterprise infrastructure. And itself is just a framework that runs in a browser that's built on top of the most popular framework ever created.

[00:09:32]
So yeah, I would say it's pretty enterprise ready. You shouldn't have any problems. Go do it. Awesome. Yeah, so thanks for taking the course, had super fun teaching it. It's definitely one of my favorite frameworks. Pretty much all I use now for almost everything. Sometimes I just go pure vanilla, but most of the time it's Next.js.

[00:09:51]
So hopefully everyone learns something from it and you can use this as a reference to go back and check things out. But like I said, I highly recommend going for it and just building more things to kinda solidify what you just learned here. Otherwise, it'll just be familiar, but it won't be something that you're really good at.

[00:10:07]
So whatever pace you are at that bootcamp that you might have went to, keep that pace, go build some new stuff. And hopefully this becomes second nature to you. So thank you for coming.
>> [APPLAUSE]