Waar Moet Ik Configuraties Plaatsen? – Een eenvoudige gids in Node.JS

tl; dr: bekijk de code repo op https://github.com/teamzerolabs/config-service-reference.

hoogstwaarschijnlijk Ja. Zolang uw programma verbinding maakt of gesprekken voert naar externe eindpunten, moet het de beveiligingsreferenties ergens vandaan halen.

er zijn veel verschillende manieren om deze referenties in het programma te laden:

niveau 1: Hard code in het tekstbestand zelf – dit gebeurt meestal op een vrijdag, of voor mensen die net beginnen. De referentie repo zou je moeten helpen om code te hebben die je kunt gebruiken in plaats van dit te doen.

niveau 2: laden van het proces.env object op de plaats waar de verbinding plaatsvindt — dit is beter dan harde codering, maar na verloop van tijd maakt de omgevingsvariabele een beetje moeilijk te volgen. Omdat je niet naar een enkel bestand kunt gaan om alle omgevingsvariabelen te vinden.

niveau 3: laad alle omgevingsconfiguraties uit een enkel bestand-Dit wordt geleverd in dit artikel en code voorbeeld! Dit geeft u het voordeel van te weten waar te gaan om configuraties op te zoeken, en laat het programma vroegtijdig mislukken als slechte waarden werden geleverd.

niveau 4: verander het configuratiescript in een service-door dit te doen, krijgen we de mogelijkheid om andere interessante dingen te doen: het type-controleren van geladen waarden, en het laden van extra configuraties van S3 of database, voordat andere initialisatie code wordt uitgevoerd.

voordat u

• start, Heeft u een knooppunt.JS runtime ready (versie > 10)
• postbode krijgen als je dat niet hebt gedaan-als alternatief kun je de browser of curl gebruiken om de Api te raken.
• Check out https://github.com/teamzerolabs/config-service-reference in uw lokale ruimte.
• heb een MySQL in werking: Ik heb een Docker-compose bestand opgenomen in de db-setup map, U kunt draaien door naar daar te gaan en docker-compose up -d uit te voeren .

een snel voorbeeld-Minimumboekdienst die boeken retourneert die zijn opgeslagen in de MySQL-database

in de eerste map node-starthere hebben we twee bestanden:

• main.js-Dit is waar we de express server instellen om het verzoek op localhost:3000/books
• models / index te dienen.js-we zullen verbinding maken met MySQL met mysql2 en sequelize .
• voer yarn start uit om te beginnen.

U kunt zien hoe de database referenties zijn opgeslagen in models/index.js :

het nadeel van harde Coderingsdatabankreferenties

• het is niet veilig-iedereen die de publieke repository uitcheckt zal nu te veel weten, vooral als uw database-instantie openbaar is, is het nu blootgesteld.
• het is moeilijk om met verschillende omgevingen te werken-als u deze code moet verbinden met testen of productie-implementaties, wilt u niet alleen code-wijzigingen uitvoeren voor implementatie.

Stap # 1-Laad elk van deze uit omgevingsvariabelen

u kunt hier meer lezen over omgevingsvariabelen. De essentie hiervan is dat je waarden kunt doorgeven aan het draaiende programma als dit

deze aanpak is prima als je een klein aantal configuraties hebt, maar zoals we allemaal weten zullen alle projecten die de eerste maand van gebruik overleefden beginnen te integreren met meer services. (Een recente 4 maanden project van mij heeft 40 variabelen! Stel je voor typen ze uit voor het garen start statement hierboven, het is te veel).

Stap # 2-Laad omgevingsvariabelen tijdens runtime voor lokale ontwikkeling voor gebruik.

gelukkig is er een pakket dat ons zal besparen om de variabelen steeds opnieuw te typen. Het wordt dotenv genoemd . U gebruikt dotenv als volgt:

Plaats uw code onder src, en maak een config map, en maak een .env bestand daarbinnen:

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

en dotenv.config zal de variabelen in de tekstbestanden laden in process.env, nu kunt u het typen van de variabelen overslaan op yarn start !

Stap#3 — Convenience methods to parse values and exit early if they are missing

het enige wat gevaarlijker is dan een verkeerd geconfigureerd programma is een verkeerd geconfigureerd programma dat maanden achtereen draait.

als we het .env bestand vergeten aan te maken, of er slechte waarden in zetten, willen we het idealiter zo vroeg mogelijk weten. Het uitvoeren van code met onvolledige of verkeerde configuratie maakt het oplossen van problemen moeilijk.

als u naar de tweede map node-with-config-service kijkt, kunt u zien dat de volgende hulpprogramma methoden zijn toegevoegd en gebruikt om de variabelen te ontleden:

en we herschrijven de database verbinding sectie naar deze:

het programma zal nu vroeg stoppen met fouten als omgevingsvariabelen ontbreken, en u kunt afhankelijk zijn van een statisch configuratieobject dat overal in het programma bestaat!

er zijn nog twee uitbreidingen voor deze aanpak — u kunt dezelfde patronen toepassen in TypeScript, en een stap verder gaan door een echte helper service in NestJS op te zetten. Beide zijn opgenomen in de git repo. We zullen deze behandelen in een toekomstig TypeScript + NestJs artikel!