Sådan kan du faktisk bruge Node-miljøvariabler

Miljøvariabler er en grundlæggende del af nodeudviklingen, men af ​​en eller anden grund har jeg aldrig gidet at lære at bruge dem korrekt.

Måske fordi de kaldes "Miljøvariabler."

Bare ordene "Miljøvariabel" udløser et PTSD-snoet flashback, hvor jeg prøver at tilføje den korrekte sti til Java Home-biblioteket i Windows. Går det i PATH eller JAVA_HOME eller begge dele? Skal jeg afslutte det med semikolon? HVORFOR BRUGER JAVA?

I Node kan miljøvariabler være globale (som på Windows), men bruges ofte med en bestemt proces, som du vil køre. For eksempel, hvis du havde en webapplikation, har du muligvis miljøvariabler, der definerer:

  • HTTP-porten, du kan lytte til
  • Databaseforbindelsesstrengen
  • JAVA_HOME ... vent ... nej - undskyld. Healingsprocessen tager tid.

I denne sammenhæng er miljøvariabler virkelig mere som "Konfigurationsindstillinger." Se hvor meget pænere det lyder?

Hvis du har gjort .NET før, er du muligvis bekendt med noget som en web.configfil. Node-miljøvariabler fungerer stort set det samme som indstillingerne i a web.config- de er en måde for dig at videregive oplysninger, som du ikke ønsker at hårdkode.

Men hvordan kan du bruge disse variabler i din Node ansøgning? Jeg havde svært ved at finde gode ressourcer til dette med den nødvendige mængde Java-vittigheder, så jeg besluttede at oprette en. Her er nogle af de forskellige måder, du kan definere og derefter læse miljøvariabler i dine Node-applikationer.

Send det i terminalen

Du kan videregive miljøvariabler på terminalen som en del af din Node-proces. For eksempel, hvis du kørte en Express-app og ønskede at passere i havnen, kunne du gøre det sådan her ...

PORT=65534 node bin/www

Sjovt faktum: port 65535 er den største tilgængelige TCP / IP-netværksværdi. Hvordan ved jeg det? StackOverflow selvfølgelig. Hvordan ved nogen noget? Men du kan kun gå så højt som port 65534 for en webapp, fordi det er den højeste port, Chrome vil oprette forbindelse til. Hvordan ved jeg det? Fordi Liran Tal fortalte mig i kommentarerne. Du burde følge ham. Mellem os to er han den der ved hvad han laver.

Nu for at bruge variablen i din kode, skal du bruge process.envobjektet.

var port = process.env.PORT;

Men dette kan blive grimt. Hvis du havde en forbindelsesstreng, vil du sandsynligvis ikke begynde at sende flere variabler på terminalen. Det ser ud til, at du skaffer konfigurationsværdier, og en, der elsker dig, kunne foretage en intervention, og det ville være akavet for alle involverede.

PORT=65534 DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9V[email protected]react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb" SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

Dette skaleres ikke, og alle vil skalere. Ifølge enhver arkitekt, jeg nogensinde har mødt med, er "skalering" vigtigere end applikationen, der endda fungerer.

Så lad os se på en anden måde: .env-filer.

Brug en .env-fil

.env-filer giver dig mulighed for at placere dine miljøvariabler i en fil. Du opretter bare en ny fil, der kaldes .envi dit projekt, og slår dine variabler derinde på forskellige linjer.

PORT=65534 DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9V[email protected]react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb" SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

For at læse disse værdier er der et par muligheder, men det nemmeste er at bruge dotenvpakken fra npm.

npm install dotenv --save

Så kræver du bare den pakke i dit projekt, hvor som helst du har brug for at bruge miljøvariabler. Den dotenvpakke vil afhente denne fil og indlæse disse indstillinger i Node.

Use dotenv to read .env vars into Node require('dotenv').config(); var MongoClient = require('mongodb').MongoClient; // Reference .env vars off of the process.env object MongoClient.connect(process.env.DB_CONN, function(err, db) { if(!err) { console.log("We are connected"); } });

PROTIP: Kontroller ikke din .envfil i Github. Det har alle dine hemmeligheder, og Github vil e-maile dig og fortælle dig det. Vær ikke som mig.

Ok rart. Men det er lidt smertefuldt. Du er nødt til at placere dette i hver enkelt fil, hvor du vil bruge miljøvariabler, OG du er nødt til at implementere den dotenvtil produktion, hvor du faktisk ikke har brug for det. Jeg er ikke en stor fan af at implementere meningsløs kode, men jeg gætter på, at jeg lige har beskrevet hele min karriere.

Heldigvis bruger du VS-kode (fordi du selvfølgelig er det ), så du har nogle andre muligheder.

Arbejde med .env-filer i VS-kode

For det første kan du installere DotENV-udvidelsen til kode, som giver dig god syntaksfremhævning i dine .env-filer.

DotENV - Visual Studio Marketplace

Udvidelse til Visual Studio-kode - Understøttelse af dotenv-filsyntaks

marketplace.visualstudio.com

VS Code Debugger tilbyder også nogle mere praktiske muligheder for at indlæse værdier fra .env-filer, hvis du bruger VS Code Debugger.

VS-kode startkonfigurationer

Node-fejlfinderen til VS-kode (allerede der, ikke nødvendigt at installere noget) understøtter indlæsning i .env-filer via startkonfigurationer. Du kan læse mere om Launch Configurations her.

Når du opretter en grundlæggende konfiguration af Node-start (klik på tandhjulet og vælg Node), kan du gøre en eller begge to ting.

Den første er, at du simpelthen kan overføre variabler til startkonfigurationen.

Dette er rart, men det faktum, at hver værdi skal være en streng, generer mig lidt. Det er et tal, ikke en streng. JavaScript har kun 3 typer. Tag ikke en af ​​dem væk fra mig.

Der er en enklere måde her. Vi har allerede lært at elske .envfiler, så i stedet for at videregive dem kan vi bare give VS-kode navnet på .env-filen.

Og så længe vi starter vores proces fra VS Code, indlæses miljøvariabelfiler. Vi behøver ikke at lemlaste tal i strenge, og vi anvender ikke værdiløs kode til produktion. Det er du i det mindste ikke.

Startende med NPM i stedet for Node

Du er måske kommet så langt og tænkte, ”Burke, jeg kører aldrig nodenoget. Det er altid et npm-script som npm start”.

I dette tilfælde kan du stadig bruge VS Code Launch-konfigurationer. I stedet for at bruge en standard Node Launch-proces tilføjer du en konfiguration, der er en "Launch Via NPM" -opgave.

Nu kan du tilføje tilbage i din envFilelinje og tilpasse den, runtimeArgsså de starter det korrekte script. Dette er normalt noget som “start” eller “debug”.

Bemærk, at du skal tilføje --inspectflag til dit npm-script, så VS-kode kan vedhæfte fejlfindingsprogrammet . Ellers starter opgaven, men VS-fejlfindingsprogrammet vil time out som jeg prøver at få en dato i gymnasiet.

Produktionsmiljøvariabler

Indtil videre har vi set på, hvordan vi definerer variabler til udvikling. Du bruger sandsynligvis ikke .env-filer i produktionen, og VS Code Launch Configurations vil ikke være meget nyttige på en server.

I produktionen defineres variabler, men din valgte platform giver dig mulighed for at gøre det. I tilfælde af Azure er der 3 forskellige måder at definere og administrere miljøvariabler på.

Den første måde er at bruge Azure CLI.

az webapp config appsettings set -g MyResourceGroup -n MyApp --settings PORT=65534

Hvilket fungerer, men ew.

En anden måde er via Azure-webportalen. Jeg bruger ikke altid en webportal, men når jeg gør det, er det at indstille miljøvariabler.

I tilfælde af Azure kaldes disse "Application Settings".

Og da du bruger VS-kode, kan du installere App Service-udvidelsen og administrere alle App-indstillinger direkte fra editoren.

Jeg elsker ikke at skulle forlade VS Code for at gøre noget. Jeg ville skrive e-mails i VS-kode, hvis jeg kunne.

VENT ET ØJEBLIK!

markdown-mail - Visual Studio Marketplace

Udvidelse til Visual Studio-kode - Brug markdown til at skrive din e-mail og sende!

marketplace.visualstudio.com

Nu ved du det

Nu ved du hvad jeg ved (hvilket ikke er meget, lad mig fortælle dig), og jeg har lyst til, at jeg nåede mit mål om en smagfuld mængde Java-vittigheder undervejs. Bare hvis jeg ikke gjorde det, forlader jeg dig med denne.

Java er et meget kraftfuldt værktøj til at gøre XML til staksspor

- Ukendt

Satire Disclaimer: Det meste af dette er et dårligt forsøg på humor, og noget af det på bekostning af Java; hvilket ikke er rart, men som er meget let. Disse vittigheder skriver ikke selv.