new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Next.js · Guides · all subjects

building/multi-zones

11 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Multi-Zones definition and purpose

Multi-Zones are an approach to micro-frontends that separate a large application on a domain into smaller Next.js applications that each serve a set of paths. This is useful when there are collections of pages unrelated to the other pages in the application. By moving those pages to a separate zone, you can reduce the size of each application which improves build times and removes code that is only necessary for one zone. Since applications are decoupled, Multi-Zones allows other applications on the domain to use their own choice of framework.

Soft navigation within same zone

Navigating between pages in the same zone performs a soft navigation, a navigation that does not require reloading the page. For example, navigating from one route to another route within the same zone will preserve the page state and resources.

Hard navigation between different zones

Navigating from a page in one zone to a page in another zone performs a hard navigation, unloading the resources of the current page and loading the resources of the new page. Pages that are frequently visited together should live in the same zone to avoid hard navigations.

assetPrefix configuration for zones

A zone is a normal Next.js application where you must configure an assetPrefix to avoid conflicts with pages and static files in other zones. Next.js assets, such as JavaScript and CSS, will be prefixed with assetPrefix to make sure that they don't conflict with assets from other zones. These assets will be served under /assetPrefix/_next/... for each of the zones. The default application handling all paths not routed to another more specific zone does not need an assetPrefix.

assetPrefix rewrite in Next.js versions before 15

In versions older than Next.js 15, you may need an additional rewrite to handle static assets. In next.config.js, add a beforeFiles rewrite that maps /assetPrefix/_next/:path+ to /_next/:path+. This is no longer necessary in Next.js 15.

Routing requests between zones using rewrites

With Multi-Zones, you need to route paths to the correct zone since they are served by different applications. To route to the correct zone using a Next.js application, use rewrites in next.config.js. For each path served by a different zone, add a rewrite rule to send that path to the domain of the other zone, and also rewrite the requests for static assets. The destination should be a URL that is served by the zone, including scheme and domain. This should point to the zone's production domain, but it can also be used to route requests to localhost in local development.

Multi-Zones rewrite example

Example of routing requests to different zones using rewrites: async rewrites() { return [ { source: '/blog', destination: `${process.env.BLOG_DOMAIN}/blog`, }, { source: '/blog/:path+', destination: `${process.env.BLOG_DOMAIN}/blog/:path+`, }, { source: '/blog-static/:path+', destination: `${process.env.BLOG_DOMAIN}/blog-static/:path+`, } ]; }

URL path uniqueness requirement in Multi-Zones

URL paths must be unique to a zone. Two zones trying to serve the same path would create a routing conflict.

Proxy routing for Multi-Zones with dynamic decisions

Routing requests through rewrites is recommended to minimize latency overhead, but proxy can be used when there is a need for dynamic decision when routing. For example, if using a feature flag to decide where a path should be routed such as during a migration, you can use proxy with NextResponse.rewrite().

Linking between zones with a tag instead of Link component

Links to paths in a different zone should use an a tag instead of the Next.js Link component. This is because Next.js will try to prefetch and soft navigate to any relative path in Link component, which will not work across zones.

Sharing code across zones

Next.js applications that make up different zones can live in any repository. However, it is often convenient to put zones in a monorepo to more easily share code. For zones that live in different repositories, code can be shared using public or private NPM packages. Since pages in different zones may be released at different times, feature flags can be useful for enabling or disabling features in unison across zones.

Give your agent this brain