Introduction to Next.js Methods of Fetching Data Review and Auth Q&A

[00:00:00]
>> So I have this thing down here that kind of walks through, when to use which mode. So I'm gonna walk through this real quick. So when to use what do you need data at runtime but you don't need SSR? Then use client-side data fetching. So pretty simple there.

[00:00:15] Do you need data at runtime but you do need SSR? Then use getServerSideProps. Do you have pages that rely on data that is cachable and accessible at build time? Like from a CMS? Then getStaticProps. Do you have the same as above but all the pages have dynamic URL parameters?

[00:00:38] Like slash ID? Then you need to do getStaticProps and getStaticPaths at the same time. And that's pretty much it when you wanna do those things. Any questions on that?
>> Are there any issues with using getServerSideProps and getStaticProps? Yeah, I know I've talked about that somewhere. Yeah, literally I talked about it over here.

[00:01:02] Okay. [LAUGH] Good. Yeah, I guess I can mention it right now. It's not recommended to use getServerSideProps unless you absolutely need it. Like if you just absolutely need server-side rendering then use it. But if you don't, don't do it, just do client side data or find a way to getStaticProps because even we getStaticProps you can still have a hybrid page which you'll see in a minute.

[00:01:26] You can still render some stuff on the server, and then do the rest on the client. You can opt in or opt out whenever you want. There's no either or, the only either or situation would be either you'd use getStaticProps or you use getServerSideProps. You can't use them both, we use either or one of these, and then static paths goes with static props.

[00:01:46] So yeah, I don't recommend using getServerSideProps unless you absolutely have to. So in a condition where you would have to it would be like I have these dynamic pages. It's like data it's always been updated. So I can't get it at build time, because maybe it's like a Twitter feed or something like that.

[00:02:04] But I need it to be indexed as well. So it's dynamic data that always changes but I also need it to be indexed and is like, okay, maybe you need server-side rendered. You probably need server-side rendering. But I would say most of the time you don't need server side rendering.

[00:02:17] If most of the time of your data is really that dynamic, then you would just do client-side fetching and hope that the crawler kind of catches it. But I would get some scenarios would be like, let's say I'm a car review website. And we have tons of car reviews and we have ads and stuff everywhere.

[00:02:33] Well, yeah, we might need server-side rendering for that. Because maybe building all those pages are really expensive and takes too long. So server-side rendering is better. You want it to be indexed, you want it to show up on social media, you want those ads to populate. But at the same time all that logic is computed at runtime, so maybe server-side rendering is good for that.

[00:02:51] But yeah most of the time, no, probably not.
>> How would you think about authentication? Where would you put it? So there's two types of authentication, right? We're talking authenticating API's and then we're talking about authenticating front end routes. Authenticating front end routes is a very similar to what you would do now.

[00:03:14] In fact, I don't think I do anything different with next.js when authenticating a front end route than what I do currently right now. Right now what I do is I use a hook to check to see if someone's authenticated. And any page that I want to be authenticated, the first thing I do is I use the hook to see they're authenticated and they're not I redirect them to the sign in page.

[00:03:34] So you still can do that on the front end. If you've ever done, I think a lot of people have used routers, features on react to use front end authentication, and that's why they might be asking the question because there's no router configuration here. So where do I do that?

[00:03:48] I use a hook. And I've always used the hook, I even did about create react app. Once I put a hook in there that checks wherever your JWT is, wherever your cookies, whatever your authentication logic is, even if you got to hit the server every time. I checked there to see if you're authenticated and redirected to a 404 and that's it for client side.

[00:04:05] And that's not specific to Next.js. For server side, if you're talking about authenticating one of these API routes that we have, then if you're using next-connect, it's very similar to what you would normally do on express. So you would say app.u or .use and then you would just do your check off middleware here, right?

[00:04:27] So if you have a check off middleware that looks something like this. Const checkAuth takes a request takes a response, right? Takes next. And then you would just say, if req.headers.authorization, right? You would check here and then if they are you call it next if they're not you respond with a 401 or whatever you wanna respond with and that's how you lock down your API.

[00:04:52] So that's authentication as well. And then authentication inside of one of these functions. Well these functions don't create resources so there's no routes or anything in these functions. These functions car resources so there really is no authentication here. But as far as getServerSideProps, you do get access to the request object which does have access to the HTTP headers.

[00:05:18] So you could check the headers of this request from the browser on getServerSideProps. So if you wanna target authentication there, you can also do that there and getServiceProps. You can't do that and getStaticProps because it's not a server. It's running at build time, it's not even in the browser yet.

[00:05:33] There's no concept of HTTP headers yet, so you won't even need it there.