Next.js hits the server first then hits the client. You can see this by doing a console log example. Server-side rendering helps limit the first contentful paint.
Part 1: Discusses the next router with useRouter in curly brackets. You don’t need switches like with React Router. Next JS has page based routing with the “pages” folder.
Part 2: “getInitialProps” function is returned and then sent to the top of the file, passed into the main component as props and then you go to user-specific page see loading until the data comes in.
Note: “getInitialProps” isn’t really a thing anymore in NextJS.
Part 3: This is a TypeScript migration video. He talks about using forms with formik as well. To migrate from TypeScript you draw out a dependency graph/mockup showing all the pages/components.
For example, you have a page, a list, and a list item. You start converting to TS at the most detailed part and then you get more broad. This way you don’t have a gazillion errors at once and you limit your headache. Start small. In his example he had a user profile which branched down into two nodes, a person detail and a vehicle list. These both had multiple nodes themselves in which some of these were TS-ready like axios, formik, and material UI. Others like the photo the yup package required some more type setup.
So to continue installing TS, once you start renaming your files from the extension of .js to .tsx and you’ll get an error in your terminal console explaining the packages you are missing. Copy the scripts from the error warning and paste to install the necessary packages. The only change he made to TS.config file was changing strict from false to true.
Part 4 – Brief Overview of API Imports:
Import next API request and next API response types from next. Bruno also used SQLite and types SQLite and showed the database connection steps.
He also imported fetch from isomorphic-unfetch, (no longer necessary per Max course?). I’ve been hearing this isomorphic term more and more as I learned about NextJS.
This API strategy is good for small apps or non-existing back end APIs.
Part 5: This is about bringing in setting up material UI. Use material UI for a table and he solved like the flickering issue bug using the _document.js file. He mentioned there’s a great Github for Vercel. He talked about the custom _app.js file which gives you access to the component tree.
Part 6: He ran through an example of authentication for API routes using Json web tokens. Mentioned that auth is both authentication and authorization. Bruno recommended hashing the user’s password with bcrypt package (Max’s course uses bcrypt-js instead) and the two routes were /sign-up and /log-in.
What I found interesting on the tokens strategy is he mentioned not sending private data like user password in the token. He described that the token has 1.) A header 2.) a payload and 3.) a verification signature.
There is a website called base64decode.org where you can paste in a JSON web token and actually decode the base 64 content!? I don’t know how easy it is for someone to get someone else’s token but this seems very unsafe. I guess everyone can see this if they decode it but if they were to make any changes to any part of the string and send back it would fail.
The tutorial series continues on by comparing storage of token in local storage versus session storage. To the pros for local storage are you protected against the CSRF and you need to add an auth token to every request and now you’re vulnerable to XSS which is cross-site scripting.
Bruno mentioned that you don’t want to store sensitive data in local storage. He also mentioned to never send password to the client even if it is hashed. He hashed using bcrypt and said to use compare() method not compareSync() per the docs, (not sure if this is a Next.js thing or what)?
He skipped validation in the tutorial. He also mentioned that if there is an error something goes wrong on validation to not send the specific error because you’re giving too much information to potential hackers, (for example, “That email is already taken”).
The benefits of session storage are you mitigate cross-site scripting if it’s set to HTTP only. The cons are that you open yourself up to a CSRF attack but you can mitigate with two-factor authentication You can protect against cross-site scripting by escaping any content. Also add secure, samesite, and HTTP only properties. Use CFRF tokens (which is what I did in the cost car cost app). Example where some banks will require you to reauthorize before a sense of transaction.
He also discussed how micro middleware works with next.js so it doesn’t work the same as Express there’s no app that use for all routes instead you use like a wrapper and you wrap in export.default function in the API. It seems like this wrapping can get pretty long.
Ch 7: consume authorization API with cookies so he pretty much just went through and ripped out tokens for cookies import cookie from cookie he did a useRef for the login form all you mentioned that this is not the right way to do it but to check other videos the input type of password hides the values which I think is interesting. He showed that to redirect using backend code in API you do router.replace(). There was also like a context.res.writehead()
Ch 8: Next.js 9.3 introduced static site generation. He shows like a microphone product website and he has a model folder and there’s a separate open DB.js file.
He uses material.UI to bring in features like an app, bar, box to help bring content down. There’s a card which has card media and card content and a grid. Because the products are the same for all users he can do static site generation here. He saves money for requests.by rendering static. Shows how getStaticProps and getStaticPaths only runs at build time and also shows you how to use pagination.
Ch. 9: Shows getServerSideProps versus getInitialProps where getServerSideProps only runs on the server the code does not run on the browser on client side. Navigation the browser calls this as an API endpoint/proxy.
With client-side rendering you go from the browser to server to database to server back to the browser so there’s like two steps. You don’t need trip to the API If you are the only one consuming endpoints there’s no third party probably don’t need to maintain the endpoints at all?
So SSR with getServerSideProps it’s the same two jumps. You go from the browser to the Next server to the database back to the next server and back to the browser.
SSR with getInitialProps has three jumps, from the browser to the Next server to the API to the database back to the API then back to the Next server and back to the browser. Checkout progress library. I don’t think getInitialProps is a thing anymore.
CSR with getInitialProps goes from the browser to the API to the database back to the API back to the browser. This is also a two-step process, just going to annAPI instead of the server.
Learned a lot here although some of the data is getting dated.
Also checkout one of his earlier videos on the SWR hook to fetch and revalidate server data.