Ето как всъщност можете да използвате променливите на средата на Node

Променливите на околната среда са основна част от разработката на Node, но по някаква причина никога не съм се занимавал с това как да ги използвам правилно.

Може би защото се наричат ​​„Променливи на околната среда“.

Само думите „Променлива на околната среда“ задействат ретроспекция, свързана с PTSD, в която се опитвам да добавя правилния път към директорията Java Home на Windows. Отива ли в PATH или JAVA_HOME или и двете? Трябва ли да го завърша с точка и запетая? ЗАЩО ИЗПОЛЗВАМ JAVA?

В Node променливите на средата могат да бъдат глобални (като в Windows), но често се използват с определен процес, който искате да стартирате. Например, ако имате уеб приложение, може да имате променливи на средата, които определят:

  • HTTP портът за слушане
  • Низът за връзка с базата данни
  • JAVA_HOME ... изчакайте ... не - съжалявам. Процесът на оздравяване отнема време.

В този контекст променливите на околната среда наистина приличат на „Настройки на конфигурацията“. Вижте колко по-приятно звучи това?

Ако вече сте правили .NET, може би сте запознати с нещо като web.configфайл. Променливите на средата на възлите работят почти по същия начин като настройките в a web.config- те са начин за предаване на информация, която не искате да кодирате твърдо.

Но как използвате тези променливи във вашето приложение Node? Трудно намерих добри ресурси за това с необходимото количество шеги на Java, затова реших да създам такъв. Ето някои от различните начини, по които можете да дефинирате и след това да четете променливи на средата във вашите Node приложения.

Предайте го в терминала

Можете да предавате променливи на средата на терминала като част от вашия Node процес. Например, ако сте използвали приложение Express и сте искали да преминете през порта, можете да го направите по този начин ...

PORT=65534 node bin/www

Забавен факт: порт 65535 е най-голямата налична стойност на TCP / IP мрежа. Как да разбера това? StackOverflow разбира се. Откъде някой знае нещо? Но можете да стигнете до порт 65534 само за уеб приложение, защото това е най-високият порт, с който Chrome ще се свърже. Как да разбера това? Защото Лиран Тал ми каза в коментарите. Трябва да го последваш. Между нас двамата той е този, който знае какво прави.

Сега, за да използвате променливата във вашия код, бихте използвали process.envобекта.

var port = process.env.PORT;

Но това може да стане грозно. Ако имате низ за връзка, вероятно не бихте искали да започнете да предавате множество променливи на терминала. Изглежда, че съхранявате конфигурационни стойности и някой, който ви обича, може да организира намеса и това би било неудобно за всички замесени.

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"

Това не се мащабира и всеки иска да мащабира. Според всеки архитект, с когото някога съм седял на среща, „мащабирането“ е по-важно, отколкото дори да работи приложението.

Така че нека разгледаме друг начин: .env файлове.

Използвайте .env файл

.env файловете ви позволяват да поставите променливите на вашата среда във файл. Просто създавате нов файл, наречен .envвъв вашия проект, и удряте вашите променливи там на различни редове.

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"

За да прочетете тези стойности, има няколко опции, но най-лесният е да използвате dotenvпакета от npm.

npm install dotenv --save

Тогава просто изисква този пакет във вашия проект, където и да е необходимо да използвате променливи на средата. В dotenvпакета ще вземе този файл и да заредите тези настройки в възел.

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"); } });

ЗАЩИТА: Не проверявайте .envфайла си в Github. В нея има всички тайни и Github ще ви изпрати имейл и ще ви каже. Не бъди като мен.

Добре, хубаво. Но това е някаква болка. Трябва да поставите това във всеки отделен файл, където искате да използвате променливи на околната среда, И трябва да внедрите инсталацията в dotenvпродукцията, където всъщност не се нуждаете от нея. Не съм голям фен на внедряването на безсмислен код, но предполагам, че току-що описах цялата си кариера.

За щастие използвате VS Code (защото разбира се, че сте ), така че имате някои други опции.

Работа с .env файлове във VS Code

Първо, можете да инсталирате разширението DotENV за код, което ще ви даде приятно подчертаване на синтаксиса във вашите .env файлове.

DotENV - Пазар на Visual Studio

Разширение за Visual Studio Code - Поддръжка на синтаксиса на dotenv файл

marketplace.visualstudio.com

VS Code Debugger предлага и някои по-удобни опции за зареждане на стойности от .env файлове, ако използвате VS Code Debugger.

Конфигурации за стартиране на VS код

Дебъгерът на Node за VS Code (вече е там, няма нужда да инсталирате нищо) поддържа зареждане в .env файлове чрез конфигурации за стартиране. Можете да прочетете повече за стартирането на конфигурациите тук.

Когато създавате основна конфигурация за стартиране на възел (щракнете върху зъбното колело и изберете Node), можете да направите едно или и двете неща.

Първото е, че можете просто да предавате променливи в конфигурацията за стартиране.

This is nice, but the fact that every value has to be a string bothers me a bit. It’s a number, not a string. JavaScript only has, like, 3 types. Don’t take one of them away from me.

There is a simpler way here. We’ve already learned to love .env files, so instead of passing them, we can just give VS Code the name of the .env file.

And as long as we are starting our process from VS Code, environment variables files are loaded in. We don’t have to mutilate numbers into strings and we aren’t deploying worthless code into production. Well, at least you aren’t.

Starting with NPM instead of Node

You might have gotten this far and thought, “Burke, I never ever run node anything. It’s always an npm script like npm start”.

In this case you can still use VS Code Launch configs. Instead of using a standard Node Launch process, you add a config that is a “Launch Via NPM” task.

Now you can add back in your envFile line and tweak the runtimeArgs so that they launch the correct script. This is usually something like “start” or “debug”.

Note that you have to add the --inspect flag to your npm script so that VS Code can attach the debugger. Otherwise the task will launch, but the VS Code debugger will time out like me trying to get a date in high school.

Production environment variables

So far we’ve looked at how to define variables for development. You likely won’t use .env files in production, and VS Code Launch Configurations aren’t going to be super helpful on a server.

In production, variables will be defined however your platform of choice allows you to do so. In the case of Azure, there are 3 different ways to define and manage environment variables.

The first way is to use the Azure CLI.

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

Which works, but, ew.

Another way is via the Azure web portal. I don’t always use a web portal, but when I do, it’s to set environment variables.

In the case of Azure, these are called “Application Settings”.

And since you are using VS Code, you can install the App Service extension and manage all the App Settings right from the editor.

I love not having to leave VS Code to do anything. I would write emails in VS Code if I could.

WAIT A MINUTE!

markdown-mail - Visual Studio Marketplace

Extension for Visual Studio Code - Using markdown to write your email and send!

marketplace.visualstudio.com

Now you know

Сега знаете какво знам (което не е много, нека ви кажа) и се чувствам така, сякаш съм постигнал целта си - вкусно количество Java шеги по пътя. Само в случай, че не го направя, ще ви оставя с този.

Java е много мощен инструмент за превръщане на XML в следи от стекове

- Неизвестно

Отказ от отговорност за сатира: Повечето от това е лош опит за хумор, а част от тях за сметка на Java; което не е хубаво, но е много лесно. Тези шеги не се пишат сами.