Dynamically Generate Next.js Pages with Server Side Rendering using getServerSideProps

Instructor: [0:00] So far, we've learned about Next.js' Static Generation method and ISR. In this exercise, we're going to explore the Server-Side Rendering method. Just like the Static Generation, SSR is another way of data fetching supported in Next.js.

[0:15] The difference between SSR and SSG, is that the in SSR, the data gets fetched for every request, while in SSG, the data used to be fetched from build time. This method is good for pages that have dynamic data -- data that changes often.

[0:30] When a user requests an SSR page, the server fetches the data. It queries the DB. It uses third-party APIs, etc. Then it generates the HTML, and then it gets it back to the browser. Compared to the SSG method, the requests in SSR are slower, but that's the price to pay to have dynamic data.

[0:51] Let's open exercise number 13. Open our pages and the index.tsx page. The initial code that we can see here is the solution to one of the previous lessons when we used the Static Generation method. Let's refactor this page to use the Server-Side Rendering method instead.

[1:12] Instead of the getStaticProps, we are going to import getServerSideProps from Next. We're going to scroll down rename the method to getServerSideProps. It will inherit from the getServerSideProps type. That's it.

[1:32] If we run npm run dev, and hit refresh, we're going to see our page functioning properly. Just to demonstrate that we are using SSR, we're going to add a console.log statement inside of the getServerSideProps. Let's logout fetching data.

[1:54] Now, let's run npm run build, so we can build the SSR page. We can also see that the index page is prefixed with a lambda symbol. That lambda symbol indicates that this page is a server-side rendered page.

[2:09] It uses either getInitialProps or getServerSideProps. Let's run npm start, and hit refresh. We can see fetching data gets logged out every time we hit refresh. Awesome. Let's talk about the differences between the getStaticProps and getServerSideProps.

[2:31] First, let's check out the context. We can see that the context is very similar to the getStaticProps context, but it has some additional properties. Like the query for example, which is an object representing the query string.

[2:46] We can use the query property to obtain the dynamic parts of our URL. We can also see the request or req for short and the response or res for short. The request property or req is the HTTP IncomingMessage object.

[3:02] Plus, it has some additional ParsingHelpers. Basically, the request is an object that contains all of the request information that the user has sent. It contains the headers, the cookies, and we can also use them to check for authorization.

[3:19] Another difference between the SSR and SSG is that for dynamic pages, we don't need to provide a method similar to the getStaticPaths because every request generates an HTML file. No HTML files need to be generated at build time.

[3:34] Let's recap. The difference between SSG and SSR was that in SSR, the page gets generated on every request. Every time a user lands on our page or we hit refresh, the Next.js server will gather all of the data needed for that page, whether we connect to a database or use third-party API services.

[3:56] Then Next.js will generate the HTML and return it back to the browser. This data-fetching method is more suitable for pages that have dynamic data, or data that changes often. Implementing SSR in a page is very similar to the Static Generation method.

[4:13] Instead, we export a getServerSideProps method. It uses the getServerSideProps type from Next. That method received a context into its arguments, just like SSG. It additionally, had the request, response and query objects.

[4:30] Unlike SSG, with SSR, we don't need to provide a method similar to the getStaticPaths when we have dynamic pages because every request generates an HTML file. No HTML files need to be generated at build time.