Zones multiples

Exemples

Les Multi-Zones sont une approche des micro-frontends qui consiste à séparer une grande application sur un domaine en plusieurs applications Next.js plus petites, chacune servant un ensemble de chemins spécifiques. Ceci est utile lorsqu'il existe des collections de pages sans rapport avec les autres pages de l'application. En déplaçant ces pages vers une zone distincte (c'est-à-dire une application distincte), vous pouvez réduire la taille de chaque application, ce qui améliore les temps de construction et supprime le code uniquement nécessaire pour l'une des zones.

Par exemple, supposons que vous ayez l'ensemble de pages suivant que vous souhaitez diviser :

  • /blog/* pour tous les articles de blog
  • /dashboard/* pour toutes les pages lorsque l'utilisateur est connecté au tableau de bord
  • /* pour le reste de votre site web non couvert par les autres zones

Avec le support des Multi-Zones, vous pouvez créer trois applications qui sont toutes servies sur le même domaine et qui paraissent identiques à l'utilisateur, mais vous pouvez développer et déployer chacune des applications indépendamment.

Trois zones : A, B, C. Montrant une navigation dure entre des routes de différentes zones, et des navigations douces entre des routes de la même zone.

Naviguer entre des pages de la même zone effectuera des navigations douces, une navigation qui ne nécessite pas de recharger la page. Par exemple, dans ce diagramme, naviguer de / vers /products sera une navigation douce.

Naviguer d'une page dans une zone vers une page dans une autre zone, comme de / vers /dashboard, effectuera une navigation dure, déchargeant les ressources de la page actuelle et chargeant les ressources de la nouvelle page. Les pages fréquemment visitées ensemble devraient se trouver dans la même zone pour éviter les navigations dures.

Comment définir une zone

Il n'y a pas d'API spéciale pour définir une nouvelle zone. Une zone est une application Next.js normale où vous configurez également un basePath pour éviter les conflits avec les pages et les fichiers statiques des autres zones.

next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  basePath: '/blog',
}

L'application par défaut qui gérera tous les chemins non envoyés à une zone plus spécifique n'a pas besoin de basePath.

Les ressources Next.js, comme JavaScript et CSS, seront également préfixées avec basePath pour s'assurer qu'elles n'entrent pas en conflit avec les ressources des autres zones. Ces ressources seront servies sous /basePath/_next/... pour chacune des zones.

Si la zone sert des pages qui ne partagent pas un préfixe de chemin commun, comme /home et /blog, vous pouvez également définir assetPrefix pour garantir que toutes les ressources Next.js sont servies sous un préfixe de chemin unique pour la zone sans ajouter de préfixe de chemin aux autres routes de votre application.

Comment router les requêtes vers la bonne zone

Avec la configuration Multi-Zones, vous devez router les chemins vers la bonne zone puisqu'ils sont servis par différentes applications. Vous pouvez utiliser n'importe quel proxy HTTP pour cela, mais l'une des applications Next.js peut également être utilisée pour router les requêtes pour l'ensemble du domaine.

Pour router vers la bonne zone en utilisant une application Next.js, vous pouvez utiliser rewrites. Pour chaque chemin servi par une zone différente, vous ajouterez une règle de réécriture pour envoyer ce chemin vers le domaine de l'autre zone. Par exemple :

next.config.js
async rewrites() {
    return [
        {
            source: '/blog',
            destination: `${process.env.BLOG_DOMAIN}/blog`,
        },
        {
            source: '/blog/:path+',
            destination: `${process.env.BLOG_DOMAIN}/blog/:path+`,
        }
    ];
}

destination devrait être une URL servie par la zone, incluant le schéma et le domaine. Cela devrait pointer vers le domaine de production de la zone, mais peut également être utilisé pour router les requêtes vers localhost en développement local.

Bon à savoir : Les chemins d'URL devraient être uniques à une zone. Par exemple, deux zones essayant de servir /blog créeraient un conflit de routage.

Lier entre les zones

Les liens vers des chemins dans une zone différente devraient utiliser une balise a au lieu du composant Next.js <Link>. C'est parce que Next.js essaiera de précharger et de naviguer doucement vers n'importe quel chemin relatif dans le composant <Link>, ce qui ne fonctionnera pas entre les zones.

Partage de code

Les applications Next.js qui constituent les différentes zones peuvent vivre dans n'importe quel dépôt. Cependant, il est souvent pratique de placer ces zones dans un monorepo pour partager plus facilement le code. Pour les zones qui vivent dans différents dépôts, le code peut également être partagé en utilisant des packages NPM publics ou privés.

Comme les pages dans différentes zones peuvent être publiées à différents moments, les fonctionnalités à bascule peuvent être utiles pour activer ou désactiver des fonctionnalités de manière synchronisée entre les différentes zones.

Pour les applications Next.js sur Vercel, vous pouvez utiliser un monorepo pour déployer toutes les zones concernées avec un seul git push.