Hová Tegyem A Konfigurációkat? – Egy egyszerű útmutató a csomópontban.JS

tl;dr: nézze meg a kód repót a https://github.com/teamzerolabs/config-service-reference címen.

valószínűleg igen. Mindaddig, amíg a program távoli végpontokhoz csatlakozik vagy hívásokat kezdeményez, valahonnan be kell szereznie a biztonsági hitelesítő adatokat.

számos különböző módon lehet betölteni ezeket a hitelesítő adatokat a programba:

1.szint: kemény kódolás magában a szövegfájlban — ez általában pénteken történik, vagy csak kezdő emberek számára. A referencia repónak segítenie kell abban, hogy rendelkezzen olyan kóddal, amelyet ahelyett, hogy ezt megtenné, felhasználhat.

2. szint: betöltése a folyamatból.env objektum azon a helyen, ahol a kapcsolat történik — ez jobb, mint a kemény kódolás, de idővel teszi a környezeti változó egy kicsit nehéz nyomon követni. Mert nem lehet egyetlen fájlba menni, hogy megtalálja az összes hivatkozott környezeti változót.

3. szint: töltse be az összes környezeti konfigurációt egyetlen fájlból — ezt a cikk és a kódpélda tartalmazza! Ez azzal az előnnyel jár, hogy tudja, hová kell mennie a konfigurációk megkereséséhez, és lehetővé teszi a program korai meghibásodását, ha rossz értékeket adtak meg.

4.szint: kapcsolja be a konfigurációs parancsfájlt szolgáltatássá — ezzel más érdekes dolgokat is elérhetünk: a betöltött értékek típusellenőrzését, valamint további konfigurációk betöltését az S3-ból vagy az adatbázisból, mielőtt más inicializálási kód futna.

mielőtt elkezdené

• van egy csomópontja.JS runtime ready (Verzió > 10)
• Get Postman ha még nem-alternatívaként, akkor a böngésző vagy a curl, hogy elérje az Api.
• nézze meg a https://github.com/teamzerolabs/config-service-reference elemet a helyi térben.
• van egy MySQL up and running: van benne egy docker-compose fájlt a db-setup mappa, akkor spin fel megy oda, és fut docker-compose up -d.

gyors példa-minimális Könyvszolgáltatás, amely visszaadja a MySQL adatbázisban tárolt könyveket

az első node-starthere mappában két fájl van:

• fő.js — itt állítjuk be a express szervert a kérés kiszolgálására localhost:3000/books
• models/index címen.js-csatlakozni fogunk a MySQL-hez mysql2 és sequelize .
• a kezdéshez futtassa a yarn start parancsot.

láthatja, hogy az adatbázis hitelesítő adatai jelenleg hogyan vannak tárolva models/index.js :

a kemény kódolású adatbázis — hitelesítő adatok hátránya

• nem biztonságos-bárki, aki megnézi a nyilvános adattárat, most túl sokat fog tudni, különösen, ha az adatbázis-példány nyilvános, most ki van téve.
• nehéz különböző környezetekkel dolgozni — ha ezt a kódot tesztelési vagy termelési telepítésekhez kell csatlakoztatnia, akkor nem csak a telepítéshez szeretné módosítani a kódot.

1.lépés — ezek mindegyikének betöltése környezeti változókból

a környezeti változókról itt olvashat bővebben. Ennek lényege, hogy értékeket adhat át a futó programba, mint ez

ez a megközelítés rendben van, ha kevés konfigurációval rendelkezik, de mint mindannyian tudjuk, minden olyan projekt, amely túlélte a használat első hónapját, több szolgáltatással integrálódik. (A legutóbbi 4 hónapos projektem 40 változóval rendelkezik! Képzelje el, hogy beírja őket a fenti fonalindítási utasításhoz, ez túl sok).

2.lépés — környezeti változók betöltése futásidőben a helyi fejlesztéshez használat előtt.

szerencsére van egy csomag, amely megment minket attól, hogy újra és újra beírjuk a változókat. Ez az úgynevezett dotenv. A dotenv-et így használod:

tedd a kódot az src alá, készíts egy konfigurációs mappát, és hozzon létre egy .env fájlt:

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

és dotenv.config betölti a változókat a szöveges fájlokat process.env, most már kihagyhatja gépelés ki a változók yarn start!

3.lépés — kényelmi módszerek az értékek elemzésére és korai kilépésre, ha hiányoznak

az egyetlen veszélyesebb dolog, mint egy rosszul konfigurált program, egy rosszul konfigurált program, amely hónapokig fut.

ha elfelejtettük elkészíteni a .env fájlt, vagy rossz értékeket tettünk bele, ideális esetben a lehető leghamarabb tudni akarjuk. A hiányos vagy rossz konfigurációjú kód futtatása megnehezíti a hibaelhárítást.

ha megnézzük a node-with-config-service második mappát, láthatjuk, hogy a következő segédprogramok kerülnek hozzáadásra és felhasználásra a változók elemzéséhez:

és átírjuk az adatbázis-kapcsolat szakaszt erre:

a program mostantól hibásan lép ki, ha a környezeti változók hiányoznak, és függhet a program bármely pontjáról létező statikus konfigurációs objektumtól!

ennek a megközelítésnek két további kiterjesztése van — ugyanazokat a mintákat alkalmazhatja a TypeScript-ben, és egy lépéssel tovább léphet egy tényleges segítő szolgáltatás beállításával a NestJS-ben. Mindkettő szerepel a git repóban. Ezeket egy jövőbeli TypeScript+NestJs cikkben fogjuk lefedni!