We know that next year's automatically tries to optimize our app by marking routes a static when it detects that they will not change over time. It renders such content only once during build time. And this would be an example of the SSG rendering strategy and we saw an example of that in a lesson on static versus dynamic rendering. This is a page that does not depend upon any dynamic APIs and therefore next years will render this statically at build time. However, if you're loading the content of a page from an external solution like an external content management system, we can mark the fetch request to load that external content with cache no store.

Once we have the content response, we can render it within the user interface. Next years, we'll automatically notice that this API call is being made with no store and therefore mark this page as dynamic and opt out of static site generation for this route. This is something that we've already looked at in a lesson on static versus dynamic rendering, but the reason of mentioning it again is to highlight it in the concept of SSG. And we've seen this output before. Static essentially means SSG or static side generation, and dynamic means SSR or server side rendering. Note that next year's caches fetch requests by default. So if you don't pass in the no store config option,

the next J will assume that this fetch request is going to always return the same response and therefore our page will no longer be dynamic and will be marked for static rendering. And we can verify that from the developer tools. The route has now been marked for static site generation. You can even take the next year's ability to generate static pages to the next level and enable it for dynamic route segments by informing next years about all the parts that the route might support. To demonstrate this, we have a dynamic page that accepts a product name in its route parameters. Because this route depends upon a past in parameter, next years will automatically mark this route

as dynamic by default. Within our page file, we export a simple component that takes the product name as a parameter and then uses it to fetch the details for the product from an external API. Once we have the product details, we render them out in a simple user interface and while we are using a product page as a demonstration, the same concept applies to various other application patterns. For example, blog posts note that we only created a single page route. However, it might service a number of different requests, for example, apple or orange or banana. And that is the reason why dynamic routes result in dynamic

pages because next J doesn't actually know what the final routes might be. Fortunately, a page route can export a method called generate static pers, which can be used to tell next J the different pers that the route supports. Next J, we'll run this function at build time to discover the different route segments. For this example, we make an API call to our content management system to get the different product names that our content has been configured for. Generate static pers must return an array of objects where the property names in the objects must match the per names for the route for our page, the per is called name. So we return an array

of objects containing the name property to verify that next J picks it up properly. We done a next build and here you can see in the build output that for the out product name next JS picked up that they might be product apple, product Orange, or product banana because those were the values returned from our CMS. And then for these values, next JS generated static HTMO for these routes. These HTMO files are written to disc and can be deployed to A CDN, which is something that a website hosting system like Versa will do by default.