Dove metto le configurazioni? – Una semplice guida nel nodo.JS

tl;dr: Controlla il repository del codice a https://github.com/teamzerolabs/config-service-reference.

Molto probabilmente sì. Finché il programma si connette o effettua chiamate a endpoint remoti, deve ottenere le credenziali di sicurezza da qualche parte.

Esistono molti modi diversi per caricare queste credenziali nel programma:

Livello 1: Codice rigido nel file di testo stesso — Questo di solito accade di venerdì, o per le persone appena agli inizi. Il repository di riferimento dovrebbe aiutarti ad avere un codice che puoi usare invece di farlo.

Livello 2: Caricamento dal processo.oggetto env nel luogo in cui avviene la connessione — Questo è meglio della codifica difficile, ma nel tempo rende la variabile d’ambiente un po ‘ difficile da tracciare. Perché non è possibile accedere a un singolo file per trovare tutte le variabili di ambiente di riferimento.

Livello 3: Carica tutte le configurazioni dell’ambiente da un singolo file-Questo è fornito in questo articolo e nell’esempio di codice! Questo ti dà il vantaggio di sapere dove andare a cercare le configurazioni e consentire al programma di fallire presto se sono stati forniti valori errati.

Livello 4: Trasforma lo script di configurazione in un servizio — Così facendo, otteniamo la possibilità di fare altre cose interessanti: controllare i valori caricati e caricare configurazioni aggiuntive da S3 o database, prima che venga eseguito un altro codice di inizializzazione.

Prima di iniziare

• Avere un Nodo.JS runtime ready (Versione > 10)
• Ottieni Postman se non l’hai fatto-In alternativa, puoi usare il browser o curl per colpire l’Api.
• Controlla https://github.com/teamzerolabs/config-service-reference nel tuo spazio locale.
• Avere un MySQL attivo e funzionante: ho incluso un file docker-compose nella cartella db-setup, puoi girare andando lì ed eseguendo docker-compose up -d.

Un rapido esempio-Minimum Book Service che restituisce i libri memorizzati nel database MySQL

Nella prima cartella node-starthere, abbiamo due file:

• principale.js-È qui che impostiamo il server express per servire la richiesta su localhost:3000/books
• models/index.js-Ci collegheremo a MySQL con mysql2 e sequelize.
• Esegui yarn start per iniziare.

Si può vedere come le credenziali del database sono attualmente memorizzati nel models/index.js :

Lo svantaggio delle credenziali del database di codifica rigida

• Non è sicuro: chiunque controlli il repository pubblico ora saprà troppo, specialmente se l’istanza del database è pubblica, ora è esposta.
• È difficile lavorare con ambienti diversi: se è necessario collegare questo codice a distribuzioni di test o di produzione, non si desidera apportare modifiche al codice solo per la distribuzione.

Passo#1 — Caricare ciascuno di questi da variabili di ambiente

Si può leggere di più sulle variabili di ambiente qui. Il succo è che puoi passare valori nel programma in esecuzione come questo

Questo approccio va bene se hai un piccolo numero di configurazioni, ma come tutti sappiamo tutti i progetti sopravvissuti al primo mese di utilizzo inizieranno ad integrarsi con più servizi. (Un mio recente progetto di 4 mesi ha 40 variabili! Immagina di digitarli per la dichiarazione di avvio del filato sopra, è troppo).

Passo#2-Caricare le variabili di ambiente in fase di runtime per lo sviluppo locale prima dell’uso.

Fortunatamente c’è un pacchetto che ci salverà dal digitare le variabili più e più volte. Si chiama dotenv. Usi dotenv in questo modo:

Metti il tuo codice in src, crea una cartella di configurazione e crea un file .env al suo interno:

DATABASE_URL=localhost
DATABASE_PORT=3306
DATABASE_USERNAME=root
DATABASE_PASSWORD=dIKnUfyfUPURi9irSplTOqGO4OtE0
DATABASE_NAME=configexample

E dotenv.config caricherà le variabili nei file di testo in process.env, ora puoi saltare digitando le variabili in yarn start!

Passo#3 — Metodi di convenienza per analizzare i valori e uscire presto se mancano

L’unica cosa più pericolosa di un programma mal configurato è un programma mal configurato in esecuzione per mesi e mesi.

Se abbiamo dimenticato di creare il file .env o di inserire valori errati, idealmente vogliamo saperlo il prima possibile. L’esecuzione di codice con configurazione incompleta o errata rende difficile la risoluzione dei problemi.

Se si guarda la seconda cartella node-with-config-service, è possibile vedere che i seguenti metodi di utilità vengono aggiunti e utilizzati per analizzare le variabili:

E riscriviamo la sezione di connessione al database in questo:

Il programma uscirà presto con errori se mancano variabili di ambiente e si può dipendere da un oggetto di configurazione statica esistente da qualsiasi parte del programma!

Ci sono altre due estensioni a questo approccio: puoi applicare gli stessi modelli in TypeScript e andare oltre impostando un servizio di supporto effettivo in NestJS. Entrambi sono inclusi nel repository git. Tratteremo questi in un futuro articolo dattiloscritto + NestJs!