Après avoir défini le bon code retour HTTP (422), nous allons maintenant paramétrer les variables dites de configuration de notre application.
Nous devons distinguer les données dites sensibles des autres.
Gérer les données sensibles
Pour éviter qu’un hacker puisse les lire facilement depuis notre fichier de configuration, nous allons ici les déplacer dans les variables d’environnement de notre Linux (ou de notre Windows).
OK, le hacker pourra également les récupérer, s’il réussit à se connecter sur notre machine … Disons que c’est une première étape pour ne pas lui ouvrir la voix directement.
Pour déclarer des variables d’environnement depuis notre Terminal de Visual Studio Code, et vu que c’est en PowerShell, nous ne pouvons pas utiliser la déclaration Batch : SET maVar=2
Nous devons utiliser la commande : $env:maVariable=”une valeur”.
Récupération depuis Node.js des variables d’environnement
Une fois paramétrées, nous pouvons les appeler depuis notre code Node.js.
Pour se faire, nous allons utiliser :
process.env.maVariable
Et oui, même ici, tout est objet dans javascript : quel bonheur !
Ainsi, sur un serveur de développement, nous aurons ces variables configurées pour le DEV, et sur le serveur de PROD, elles seront configurées pour la PROD.
Plus besoin d’y penser !
Gérer les données moins sensibles
Nous avons des données moins sensibles (comme l’identifiant de l’automation active campaign à utiliser). Nous pouvons également les stocker dans les variables d’environnement.
En fait, tout peut être stocké dans les variables d’environnement.
Nous allons cependant garder le principe que toute donnée moins sensible sera dans un fichier de configuration json.
Avoir un système de configuration par environnement
OK, nous allons avoir un fichier de configuration. Quid de nos différents environnements de travail : DEV, REC, PROD ?
Comment faire pour avoir le bon fichier de configuration suivant l’environnement où sera déposé l’API ?
Utilisation du package config
C’est ici qu’intervient le package config.
En créant un fichier de configuration default.json (où nous aurons toute notre configuration, déclarée en json), nous pourrons l’appeler grâce au package config :
config.get(“moncheminsjon.mavariable”).
Clou du spectacle ? Nous allons pouvoir définir un nouveau fichier, par exemple : production.json, qui sera le fichier de configuration pour la PROD !
Et hop, suivant la configuration définie sur notre serveur, le package config prendra automatiquement le fichier adéquat !
Note : il faut respecter dans chacun des fichiers, définis par environnement, la même structure json.