Node.js: Differenze tra sviluppo e produzione

Non esiste alcuna differenza tra sviluppo e produzione in Node.js, ovvero non è necessario applicare impostazioni specifiche per far funzionare Node.js in una configurazione di produzione. Tuttavia, alcune librerie nel registro npm riconoscono l'utilizzo della variabile NODE_ENV e la impostano di default su development. Eseguire sempre Node.js con NODE_ENV=production impostato.

Un modo popolare per configurare la tua applicazione è usare la metodologia twelve-factor.

NODE_ENV in Express

Nel famoso framework express, impostare NODE_ENV su produzione generalmente garantisce che:

• la registrazione sia ridotta al minimo, livello essenziale
• vengano implementati più livelli di caching per ottimizzare le prestazioni

Questo si fa solitamente eseguendo il comando

export NODE_ENV=production

nella shell, ma è meglio inserirlo nel file di configurazione della shell (es. .bash_profile con la shell Bash) perché altrimenti l'impostazione non persiste in caso di riavvio del sistema.

È anche possibile applicare la variabile di ambiente anteponendola al comando di inizializzazione dell'applicazione:

NODE_ENV=production node app.js

Ad esempio, in un'app Express, puoi usare questo per impostare diversi gestori di errori per ambiente:

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

Ad esempio Pug, la libreria di templating utilizzata da Express.js, compila in modalità debug se NODE_ENV non è impostato su production. Le viste di Express vengono compilate ad ogni richiesta in modalità sviluppo, mentre in produzione vengono memorizzate nella cache. Ci sono molti altri esempi.

Questa variabile di ambiente è una convenzione ampiamente utilizzata nelle librerie esterne, ma non all'interno di Node.js stesso.

Perché NODE_ENV è considerato un antipattern?

Un ambiente è una piattaforma digitale o un sistema in cui gli ingegneri possono costruire, testare, distribuire e gestire prodotti software. Convenzionalmente, ci sono quattro fasi o tipi di ambienti in cui viene eseguita la nostra applicazione:

• Sviluppo
• Staging
• Produzione
• Test

Il problema fondamentale di NODE_ENV deriva dagli sviluppatori che combinano ottimizzazioni e comportamento del software con l'ambiente in cui viene eseguito il loro software. Il risultato è codice come il seguente:

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

Anche se questo potrebbe sembrare innocuo, rende diversi gli ambienti di produzione e staging, rendendo impossibile un test affidabile. Ad esempio, un test e quindi una funzionalità del tuo prodotto potrebbero riuscire quando NODE_ENV è impostato su development ma fallire quando si imposta NODE_ENV su production. Pertanto, impostare NODE_ENV su qualsiasi valore diverso da production è considerato un antipattern.