Runtimes Edge et Node.js

Dans le contexte de Next.js, un runtime désigne l'ensemble des bibliothèques, API et fonctionnalités générales disponibles pour votre code lors de son exécution.

Sur le serveur, il existe deux runtimes où des parties de votre code applicatif peuvent être rendues :

• Le Runtime Node.js (par défaut) a accès à toutes les API Node.js et aux packages compatibles de l'écosystème.
• Le Runtime Edge est basé sur les API Web.

Différences entre les runtimes

Plusieurs éléments sont à prendre en compte lors du choix d'un runtime. Ce tableau présente les principales différences en un coup d'œil. Pour une analyse plus approfondie, consultez les sections ci-dessous.

Runtime Edge

Dans Next.js, le runtime Edge léger est un sous-ensemble des API Node.js disponibles.

Le runtime Edge est idéal si vous avez besoin de fournir du contenu dynamique et personnalisé avec une faible latence, à l'aide de fonctions simples et légères. La rapidité du runtime Edge provient de son utilisation minimale de ressources, mais cela peut être limitant dans de nombreux scénarios.

Par exemple, le code exécuté dans le runtime Edge sur Vercel ne peut pas dépasser entre 1 Mo et 4 Mo. Cette limite inclut les packages importés, les polices et les fichiers, et peut varier selon votre infrastructure de déploiement. De plus, le runtime Edge ne prend pas en charge toutes les API Node.js, ce qui signifie que certains packages npm peuvent ne pas fonctionner. Par exemple, des erreurs comme "Module not found: Can't resolve 'fs'" ou similaires. Nous recommandons d'utiliser le runtime Node.js si vous avez besoin d'utiliser ces API ou packages.

Runtime Node.js

L'utilisation du runtime Node.js vous donne accès à toutes les API Node.js et à tous les packages npm qui en dépendent. Cependant, son démarrage n'est pas aussi rapide que celui des routes utilisant le runtime Edge.

Le déploiement de votre application Next.js sur un serveur Node.js nécessitera de gérer, mettre à l'échelle et configurer votre infrastructure. Vous pouvez également envisager de déployer votre application Next.js sur une plateforme serverless comme Vercel, qui s'en chargera pour vous.

Node.js Serverless

Le serverless est idéal si vous avez besoin d'une solution évolutive capable de gérer des charges de calcul plus complexes que le runtime Edge. Avec les fonctions serverless sur Vercel, par exemple, la taille totale de votre code est de 50 Mo, y compris les packages importés, les polices et les fichiers.

L'inconvénient par rapport aux routes utilisant le runtime Edge est que le démarrage des fonctions serverless peut prendre des centaines de millisecondes avant de commencer à traiter les requêtes. Selon le trafic de votre site, cela peut se produire fréquemment, car les fonctions ne sont pas souvent "chaudes".

Exemples

Option de runtime par segment

Vous pouvez spécifier un runtime pour des segments de route individuels dans votre application Next.js. Pour ce faire, déclarez une variable appelée runtime et exportez-la. La variable doit être une chaîne de caractères et avoir pour valeur soit 'nodejs', soit 'edge'.

L'exemple suivant montre un segment de route de page qui exporte une runtime avec la valeur 'edge' :

export const runtime = 'edge' // 'nodejs' (par défaut) | 'edge'

export const runtime = 'edge' // 'nodejs' (par défaut) | 'edge'

Vous pouvez également définir runtime au niveau d'un layout, ce qui fera fonctionner toutes les routes sous ce layout avec le runtime Edge :

export const runtime = 'edge' // 'nodejs' (par défaut) | 'edge'

export const runtime = 'edge' // 'nodejs' (par défaut) | 'edge'

Si le runtime du segment n'est pas défini, le runtime par défaut nodejs sera utilisé. Vous n'avez pas besoin d'utiliser l'option runtime si vous ne prévoyez pas de changer du runtime Node.js.

Consultez la documentation Node.js et la documentation Edge pour la liste complète des API disponibles. Les deux runtimes peuvent également prendre en charge le streaming selon votre infrastructure de déploiement.