Composition, Caching, and Architecture in modern Next.js

[Music] Okay. Hello everyone. My name is Aurora. I'm a web developer from Norway. I work as a consultant uh at Crane Consulting also. And I'm actively building with an XJS app router in my current consultancy project. Today I'm going to be teaching you patterns regarding composition, caching, and architecture in modern XJS that will help you ensure scalability and performance. Let me first first refresh the most fundamental concepts for this talk. static and dynamic rendering. We

encounter them both in the nextG app router. Static rendering allows us to build faster websites because pre-rendered content can be cached and globally distributed, ensuring users can access it quicker. For example, the next comp website. Static rendering reduces server load because content does not have to be generated for each user request. Pre-render content is also easier for search engine crawers to index as the content is already available on page load. Dynamic rendering on the other hand

allows our application to display real-time or frequently updated data. It also enables us to serve personalized content such as dashboards and user profiles. For example, the Versell dashboard. With dynamic rendering, we can access information that can only be known at request time. In this case, which user is accessing their dashboard, which is me. There are certain APIs that can cause a page to dynamically render. Usage of the params and search params props that are passed to pages or their equivalent hooks will cause dynamic rendering.

However, with params, we can predefine a set of pre-rendered pages using generate static params and we can also cache the pages as they're being generated by users. Furthermore, reading incoming request cookies and headers will opt the page into dynamic rendering. Unlike with params though trying to cache or preender anything using headers or cookies will throw errors during build because that information cannot be known ahead of time. Lastly using fetch with a data cache configuration no store will also force dynamic rendering. So these are the few

uh there are a few more APIs that can cause dynamic rendering but these are the ones we most commonly encounter. In previous versions of next uh a page would be rendered either as fully static or fully dynamic. one single dynamic API on a page without the whole page into dynamic rendering. For example, doing a simple off check for the value of a cookie. By utilizing React server components with suspense, we can stream in dynamic content like a personalized welcome banner or recommendations as they become ready and provide only fallbacks with

suspense while showing static content like a newsletter. However, once we add in multiple async components on a dynamic page like a feature product, they too would run at request time even though they didn't depend on dynamic APIs. So to avoid blocking the initial page load, we would suspend and stream those components uh down as well doing extra work creating skeletons and worrying about things like human layout shift. However, pages are often a mix of static

and dynamic content. for example, an e-commerce app dependent on user information while still containing mostly static data. Being forced to pick being forced to pick between them um between static or dynamic causes lots of redundant processing on the server on content that uh never or very rarely changes and isn't optimal for performance. So to solve this problem at last year's nextJS comp the user use cache directive was announced and this year as we saw in the keynote it's available in the next in nextg 16. So with use cache pages

will no longer be forced into either static or dynamic rendering. They can be both and next.js no longer has to guess what a page is based on whether it accesses things like params. Everything is dynamic by default and use cache let us explicitly opt into caching. Use cache enables composable caching. We can mark either a page, a react component or function as cachable. Here we can actually cach the feature products component because it does not