When it comes to rendering content in modern web applications, there are a few terms that developers use, like S-S-R-S-S-D, and ISR. Let's simplify them. Before we dissect these terms, it's important to understand the difference between built time and request time. We know that before our code can be deployed to a server, we need to run next build. This can be done locally or by our continuous delivery pipeline, and we saw an example of the CEL Built pipeline in our lesson on next year's deployment. Things that occur during the act of building our application with next build is

what we are calling build time activities. After we deploy our application to a hosting provider, are built code executing on a server can start servicing requests to return appropriate responses. Things that occur during the act of responding to a request is what we call request time activities. Put simply Build time is when we are building our application and request time is when we are responding to an incoming request. With these concepts out of the way, let's take a look at the different rendering strategies. SSR stands for server side rendering. With SSR, our content is rendered on the

server at request time. This means that when a user requests a page and the server is processing the request, it renders our components to get the generated HTMO and sends it back to the client. This approach is particularly useful for dynamic content that needs to be up to date. So when a new request comes in, new content is generated and sent back. SSG stands for Static Site Generation. The objective of SSG is to pre gender our site into static HTML files. At build time. With SSG, we render out components during the build process. When we deploy our site,

we can host the generated files on our server or even an external CDN or content delivery network, which is closer to the user for even faster response times. So when a request comes in, we don't need to execute our code to get the rendered response and instead simply return the pre-printed content. SSG has a number of benefits. The biggest ones are improved response times and decreased usage of server resources while improved performance is great. This does have the drawback that the content we want to display is predetermined at build time, which means that we cannot use it with dynamic data.

ISR stands for incremental static regeneration. It is a hybrid approach that combines the benefits of both SSR and SSG. With ISR content is initially generated statically like SSG, but after that it can be regenerated in the background. Like SSR, this allows you to update the content from time to time without the need to rebuild the entire site. For example, initially we generate the static pages at build time like SSG and deploy them to our site. But after a predetermined condition, like a duration or a triggered event, we update the generated files so that they contain fresh content.

You can think of ISR as SSR plus caching. With ISR, we get the fast response times of static site generation and dynamic content support of server site rendering. The good news is that next year is a hybrid framework that allows you to move the slider from full static build time rendering to full dynamic request time rendering, and anywhere in between by using its various APIs and configuration options. Thank you for joining me, and I'll see you in the next one.