Artigo original: Here’s how you can actually use Node environment variables
As variáveis de ambiente são uma parte fundamental do desenvolvimento em Node. Por alguma razão, porém, nunca fui atrás de como usá-las adequadamente.
O motivo é, possivelmente, o fato de elas serem chamadas de "variáveis de ambiente".
A expressão "variáveis de ambiente" por si só é um gatilho para o meu trauma de tentar adicionar o caminho correto para o diretório Home do Java no Windows. Devo usar PATH ou JAVA_HOME? Ou ambos? Preciso colocar ponto e vírgula no final? POR QUE RAIOS ESTOU USANDO JAVA?
No Node, as variáveis de ambiente podem ser globais (como no Windows), mas geralmente são usadas em um processo específico que você deseja executar. Por exemplo, se você tiver uma aplicação para a web, talvez tenha variáveis de ambiente que definem:
- A porta HTTP a ser monitorada
- A string que conecta ao banco de dados
- O JAVA_HOME... espere... isso não — desculpe. Ainda estou me recuperando do trauma.
Em contextos assim, as variáveis de ambiente são realmente mais como "ajustes de configuração". Viu como soa melhor dessa maneira?
Se você tem alguma experiência com .NET, talvez esteja familiarizado com o arquivo web.config. As variáveis de ambiente do Node funcionam de um jeito parecido com os ajustes feitos no web.config — são, basicamente, um modo de passar informações que você não quer deixar no código fonte.
Como usar essas variáveis na sua aplicação do Node? Foi difícil encontrar esse conteúdo com a dose necessária de piadas com Java. Portanto, decidi criar eu mesmo. Aqui estão algumas maneiras de definir e de ler variáveis de ambiente nas suas aplicações do Node.
Passando no terminal
Você pode passar variáveis de ambiente diretamente no terminal como parte do processo da sua aplicação do Node. Por exemplo: se você estiver rodando uma aplicação com o framework Express e se quiser passar um conteúdo para a porta 65534, pode fazer da seguinte maneira...
PORT=65534 node bin/wwwCuriosidade: a porta 65535 é o maior valor de rede TCP/IP disponível. Como eu sei disso? StackOverflow, é claro (texto em inglês). De que outra maneira as pessoas sabem das coisas? Só podemos, no entanto, chegar à porta 65534 para uma aplicação da web porque essa é a maior porta a qual o Chrome se conecta. Como eu sei isso? O Liran Tal me disse nos comentários. Recomendo segui-lo. Diferente de mim, ele sabe o que está fazendo.
Para o caso de usar a variável no seu código, você poderia usar o objeto process.env.
var port = process.env.PORT;Aí, a coisa pode ficar feia. Se você tivesse uma string de conexão, provavelmente não gostaria de passar um monte variáveis no terminal. Isso faria parecer que você está acumulando diversos valores de configuração. Uma pessoa que se importa com você poderia organizar uma intervenção; o que seria constrangedor para todos os envolvidos.
PORT=65534
DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9VXh29T9U8xQNVGQ78lEQaL6yMNq3rOSA1WhUXHTOcmDf38Q8rg14NHtQLcUuMA==@react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb"
SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"Isso não escala – e todo mundo quer escalar. De acordo com todos os arquitetos que conheci, a aplicação "escalar" é mais importante do que a aplicação funcionar.
Sendo assim, vamos tentar outra abordagem: os arquivos .env.
Usando um arquivo .env
O que os arquivos .env fazem é nos permitir armazenar nossas variáveis em um arquivo à parte. Você só precisa criar um arquivo .env no seu projeto e colocar as variáveis nele em linhas separadas.
PORT=65534
DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9VXh29T9U8xQNVGQ78lEQaL6yMNq3rOSA1WhUXHTOcmDf38Q8rg14NHtQLcUuMA==@react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb"
SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"Existem diferentes maneiras de se ler esses valores, mas a opção mais simples é usar o pacote dotenv via npm.
npm install dotenv --saveFeito isso, você só precisa fazer uma requisição desse pacote no seu projeto sempre que precisar usar suas variáveis de ambiente. O pacote dotenv vai pegar o respectivo arquivo e carregar suas configurações no Node.
// Usando o dotenv para ler variáveis de um arquivo .env no Node:
require('dotenv').config();
var MongoClient = require('mongodb').MongoClient;
// Referenciando variáveis .env fora do objeto process.env:
MongoClient.connect(process.env.DB_CONN, function(err, db) {
if(!err) {
console.log("Conectado");
}
});Dica importante: Não suba seus arquivos .env para o Github. Os valores armazenados ali devem ser mantidos em sigilo. O próprio Github vai enviar a você um e-mail alertando sobre isso. Não faça a mesma besteira que eu.
Certo — bacana. Isso, porém, é meio chato. Você precisa colocar esse código em cada arquivo em que deseja usar variáveis de ambiente E você deve enviar o dotenv para o ambiente de produção, onde não é exatamente necessário. Não sou muito fã de fazer deploy de código inútil, mas acho que isso descreve a minha carreira como um todo.
Felizmente, você está usando o VS Code (você está usando o VS Code, certo?). Então, você tem algumas outras opções.
Trabalhando com arquivos .env no VS Code
Primeiramente, saiba que você pode instalar a extensão DotENV no seu VS Code. Ela vai fornecer um destaque visual na sintaxe dos seus arquivos .env.
DotENV - Visual Studio Marketplace
O depurador do VS Code também oferece algumas opções mais convenientes para carregar valores de arquivos .env. Isso se você estiver usando o depurador do VS Code.
Configurações de execução do VS Code
O depurador do Node para o VS Code (que já está presente nele – não precisa instalar nada para usá-lo) tem suporte para carregamento em arquivos .env por meio de configurações de execução. Leia mais sobre configurações de execução aqui (texto em inglês).
Quando você cria uma configuração de execução básica do Node (clique na engrenagem e selecione "Node"), você pode fazer uma ou as duas seguintes ações:
A primeira é você simplesmente passar as variáveis para a configuração de execução.
É bacana e tal, mas, aqui, todos os valores precisam ser strings. Isso me incomoda um pouco. É um número, não uma string. O JavaScript só tem 3 tipos. Não quero perder um deles.
Existe um caminho mais fácil. Nós já aprendemos a amar os arquivos .env. Então, ao invés de passar os seus valores, podemos simplesmente informar ao VS Code o nome do arquivo .env em questão.
Desse modo, contanto que iniciemos nosso processo a partir do VS Code, os arquivos de variáveis de ambiente serão carregados. Não precisamos "mutilar" os números transformando-os em strings. Também não estamos enviando código inútil para o ambiente de produção. Ou, pelo menos, você não está.
Começando com o NPM ao invés do Node
Você pode ter chegado aqui pensando: "Burke, eu nunca rodei nada com o comando node. É sempre um script do npm como npm start".
Para casos assim, também é possível usar as configurações de execução do VS Code. Ao invés de usar um processo de execução padrão do Node, você adiciona a configuração "Launch Via NPM" (Executar via NPM).
Agora, você pode adicionar novamente seu arquivo .env na linha envFile e ajustar a linha runtimeArgs para rodar o script correto. Isso normalmente é feito com um comando "start" ou "debug".
Lembre-se de adicionar a flag --inspect ao seu script npm para que o VS Code possa vincular o depurador a ele. Do contrário, a tarefa até vai ser executada, mas o depurador do VS Code vai desistir de continuar – assim como eu, tentando arranjar um encontro no ensino médio.
Variáveis de ambiente em produção
Até agora, vimos como definir variáveis para o ambiente de desenvolvimento. Você provavelmente não vai usar arquivos .env em produção. As configurações de execução do VS Code não vão ser muito úteis em um servidor.
Em produção, as variáveis serão definidas de acordo com a sua plataforma escolhida. Se for a Azure, existem 3 maneiras diferentes de definir e gerenciar suas variáveis de ambiente.
A primeira maneira é usar o Azure CLI.
az webapp config appsettings set -g MyResourceGroup -n MyApp --settings PORT=65534Até funciona, mas... eca.
Outra maneira é usar o Azure Web Portal. Eu nem sempre uso um portal da web, mas, quando uso, é para definir variáveis de ambiente.
Na nomenclatura da Azure, elas são chamadas de "Application Settings" (Configurações da aplicação).
Porém, como você está usando o VS Code, pode instalar a extensão Azure App Service para gerenciar todas as configurações da aplicação diretamente do seu editor.
Adoro não precisar sair do VS Code. Eu escreveria e-mails no VS Code, se pudesse.
UM MOMENTO!
markdown-mail - Visual Studio Marketplace
Agora você já sabe
Agora você já sabe o que eu sei — o que não é muito, diga-se de passagem — e sinto que cumpri meu objetivo de fornecer uma pitada de piadas com Java ao longo do caminho. Porém, caso eu não tenha conseguido, aqui vai uma:
Java é uma ferramenta muito poderosa para transformar XML em traços de erro.
- Autor desconhecido
Observação: a maior parte das piadas é apenas uma tentativa ruim de fazer humor, parte dessa tentativa feita às custas do Java. Sei que não é legal fazer isso, mas, com o Java, é bem fácil. Afinal, as piadas não se escrevem sozinhas.