Où Placer Les Configurations ? – Un guide simple dans le Nœud.JS

tl; dr: Consultez le dépôt de code à https://github.com/teamzerolabs/config-service-reference.

Très probablement oui. Tant que votre programme se connecte ou passe des appels vers des terminaux distants, il doit obtenir les informations d’identification de sécurité de quelque part.

Il existe de nombreuses façons de charger ces informations d’identification dans le programme:

Niveau 1: Codez-le en dur dans le fichier texte lui—même – Cela se produit généralement un vendredi, ou pour les débutants. Le référentiel de référence devrait vous aider à avoir du code que vous pouvez utiliser au lieu de le faire.

Niveau 2: Chargement à partir du processus.objet env à l’endroit où la connexion se produit — C’est mieux que le codage en dur, mais au fil du temps rend la variable d’environnement un peu difficile à suivre. Parce que vous ne pouvez pas accéder à un seul fichier pour trouver toutes les variables d’environnement référencées.

Niveau 3: Chargez toutes les configurations d’environnement à partir d’un seul fichier — Ceci est fourni dans cet article et cet exemple de code ! Cela vous donne l’avantage de savoir où aller pour rechercher des configurations et de permettre au programme d’échouer tôt si de mauvaises valeurs ont été fournies.

Niveau 4 : Transformez le script de configuration en service — Ce faisant, nous gagnons la possibilité de faire d’autres choses intéressantes : la vérification de type des valeurs chargées et le chargement de configurations supplémentaires à partir de S3 ou de la base de données, avant l’exécution d’un autre code d’initialisation.

Avant de commencer

• Avoir un nœud.Prêt pour le runtime JS (Version > 10)
• Obtenez Postman si vous ne l’avez pas fait — Vous pouvez également utiliser le navigateur ou curl pour accéder à l’API.
• Consultez https://github.com/teamzerolabs/config-service-reference dans votre espace local.
• Avoir un MySQL opérationnel: j’ai inclus un fichier docker-compose dans le dossier db-setup, vous pouvez le faire tourner en y allant et en exécutant docker-compose up -d.

Un exemple rapide — Service de livre minimum qui renvoie des livres stockés dans la base de données MySQL

Dans le premier dossier node-starthere, nous avons deux fichiers:

• principal.js – C’est là que nous configurons le serveur express pour servir la requête à localhost:3000/books
• modèles/index.js – Nous allons nous connecter à MySQL avec mysql2 et sequelize.
• Exécutez yarn start pour commencer.

Vous pouvez voir comment les informations d’identification de la base de données sont actuellement stockées dans models/index.js :

L’inconvénient des informations d’identification de base de données de codage en dur

• Ce n’est pas sécurisé — Quiconque vérifie le référentiel public en saura désormais trop, surtout si votre instance de base de données est publique, elle est maintenant exposée.
• Il est difficile de travailler avec différents environnements — Si vous devez connecter ce code à des déploiements de test ou de production, vous ne souhaitez pas modifier le code uniquement pour le déploiement.

Étape #1 – Chargez chacune de ces variables à partir de variables d’environnement

Vous pouvez en savoir plus sur les variables d’environnement ici. L’essentiel est que vous pouvez transmettre des valeurs au programme en cours d’exécution comme ceci

Cette approche convient si vous avez un petit nombre de configurations, mais comme nous le savons tous, tous les projets qui ont survécu au premier mois d’utilisation commenceront à s’intégrer à plus de services. (Un projet récent de 4 mois a 40 variables! Imaginez les taper pour l’instruction yarn start ci-dessus, c’est trop).

Étape #2 – Chargez les variables d’environnement à l’exécution pour le développement local avant utilisation.

Heureusement, il existe un package qui nous évitera de taper les variables encore et encore. Il s’appelle dotenv. Vous utilisez dotenv comme ceci:

Placez votre code sous src, créez un dossier de configuration et créez un fichier .env à l’intérieur:

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

Et dotenv.config chargera les variables dans les fichiers texte dans process.env, maintenant vous pouvez sauter en tapant les variables à yarn start!

Étape #3 – Méthodes pratiques pour analyser les valeurs et quitter tôt si elles manquent

La seule chose plus dangereuse qu’un programme mal configuré est un programme mal configuré qui s’exécute pendant des mois.

Si nous avons oublié de créer le fichier .env ou d’y mettre de mauvaises valeurs, idéalement, nous voulons le savoir le plus tôt possible. L’exécution de code avec une configuration incomplète ou incorrecte rend le dépannage difficile.

Si vous regardez le deuxième dossier node-with-config-service, vous pouvez voir que les méthodes utilitaires suivantes sont ajoutées et utilisées pour analyser les variables:

Et nous réécrivons la section de connexion à la base de données:

Le programme se terminera maintenant tôt avec des erreurs si des variables d’environnement sont manquantes, et vous pouvez compter sur un objet de configuration statique existant de n’importe où dans le programme!

Il existe deux autres extensions à cette approche : Vous pouvez appliquer les mêmes modèles dans TypeScript et aller plus loin en configurant un service d’assistance réel dans NestJS. Les deux sont inclus dans le dépôt git. Nous les couvrirons dans un futur article TypeScript + NestJs!