Node.js, la différence entre développement et production

Il n'y a pas de différence entre le développement et la production dans Node.js, c'est-à-dire qu'il n'y a pas de paramètres spécifiques à appliquer pour que Node.js fonctionne dans une configuration de production. Cependant, quelques bibliothèques du registre npm reconnaissent l'utilisation de la variable NODE_ENV et la définissent par défaut sur un paramètre development. Exécutez toujours votre Node.js avec NODE_ENV=production défini.

Une façon populaire de configurer votre application est d'utiliser la méthodologie douze facteurs.

NODE_ENV dans Express

Dans le framework très populaire express, définir NODE_ENV sur production garantit généralement que :

• la journalisation est réduite au minimum, niveau essentiel
• davantage de niveaux de mise en cache ont lieu pour optimiser les performances

Cela se fait généralement en exécutant la commande

export NODE_ENV=production

dans le shell, mais il est préférable de la placer dans votre fichier de configuration du shell (par exemple .bash_profile avec le shell Bash) car sinon le paramètre ne persiste pas en cas de redémarrage du système.

Vous pouvez également appliquer la variable d'environnement en la préfixant à votre commande d'initialisation de l'application :

NODE_ENV=production node app.js

Par exemple, dans une application Express, vous pouvez utiliser ceci pour définir des gestionnaires d'erreurs différents par environnement :

if (process.env.NODE_ENV === 'development') {
  app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
}
if (process.env.NODE_ENV === 'production') {
  app.use(express.errorHandler());
}

Par exemple [Pug](https://pugjs.org], la bibliothèque de modèles utilisée par [Express.js](https://expressjs.com], compile en mode débogage si NODE_ENV n'est pas défini sur production. Les vues Express sont compilées à chaque requête en mode développement, tandis qu'en production elles sont mises en cache. Il existe de nombreux autres exemples.

Cette variable d'environnement est une convention largement utilisée dans les bibliothèques externes, mais pas dans Node.js lui-même.

Pourquoi NODE_ENV est-il considéré comme un anti-pattern ?

Un environnement est une plateforme numérique ou un système où les ingénieurs peuvent construire, tester, déployer et gérer des produits logiciels. Conventionnellement, il existe quatre étapes ou types d'environnements où notre application est exécutée :

• Développement
• Mise en scène
• Production
• Tests

Le problème fondamental de NODE_ENV provient du fait que les développeurs combinent les optimisations et le comportement du logiciel avec l'environnement sur lequel leur logiciel s'exécute. Le résultat est un code comme celui-ci :

if (process.env.NODE_ENV === 'development') {
  // ...
}
if (process.env.NODE_ENV === 'staging') {
  // ...
}
if (process.env.NODE_ENV === 'production') {
  // ...
}
if (process.env.NODE_ENV === 'testing') {
  // ...
}

Bien que cela puisse sembler inoffensif, cela rend les environnements de production et de mise en scène différents, rendant ainsi les tests fiables impossibles. Par exemple, un test et donc une fonctionnalité de votre produit pourraient réussir lorsque NODE_ENV est défini sur development mais échouer lors de la définition de NODE_ENV sur production. Par conséquent, définir NODE_ENV sur autre chose que production est considéré comme un anti-pattern.