Gerenciando variáveis ambiente no Node.js
Se existe uma coisa que a grande maioria dos projetos de desenvolvimento tem em comum é que e eles possuem dados sensíveis, como informações do banco de dados, chaves de API's, Secret Keys entre outras informações de configuração necessárias.
Mas como proceder com essas informações? Elas devem ficar dando sopa por aí no seu repositório? É sobre isso que o post de hoje vai tratar! Sobre variáveis de ambiente e como lidar com elas.
Dotenv
Essa é a ferramenta utilizada para orquestrar as variáveis ambiente de um projeto. O nome dela sugere o arquivo em que as informações ficarão,
dot que é ponto em inglês acrescido de env, então temos o arquivo .env que é composto de chaves e valores.Uma curiosidade é que em sistemas baseados em unix arquivos que iniciam com
. são ocultos, talvez seja uma sugestão da tarefa desse arquivo.Você pode adicionar facilmente ao seu projeto o
dotenv pelo npm ou yarn.No arquivo
.env as informações ficarão no formato chave e valor, como segue:APP_NAME=Rocketseat Blog SECRET_API=9as1%12#xz0#@ CPUS=4 # Banco de dados DB_NAME=rocketseat DB_PASS= DB_HOST=localhost # Stack STACK=["React Native", "ReactJS", "NodeJS"]
Você pode tirar as seguintes conclusões desse arquivo:
- As chaves são em caixa alta, por padrão e não exigência;
- As chaves não podem ter espaço;
- Os valores podem ser quaisquer tipo, que será retornado sempre uma
string;
- Pode haver espaçamentos, porém é feito um
trimnastring;
- Pode existir chave sem valor, que retorna uma
stringvazia;
Com o arquivo
.env configurado é necessário executar o dotenv que irá chama-lo para ler as variáveis e adiciona-las ao processo que o executou, sabendo que para acessar as informações use process.env.[NOME_DA_CHAVE].require('dotenv/config'); console.log(process.env.APP_NAME) // Rocketseat Blog
Boas práticas e cuidados
Por se tratar de informações sensíveis na sua maioria é importante que esses dados só fiquem em seu ambiente de desenvolvimento, então se você pretende compartilhar seu código lembre-se de remover esse arquivo.
Caso utilize o github basta adicionar ao
.gitignore o arquivo .env para ele fazer esse trabalho para você.Uma boa prática também é criar um arquivo de exemplo com as chaves que seu projeto está utilizando, sem os valores sensíveis, assim quem clonar seu repositório ou ter acesso ao seu fonte não ficará perdido.
Eu crio um
.env.example e deixo apenas informações genéricas como é o caso do APP_NAME.Ambiente de teste
Geralmente para nossos testes temos um banco de dados exclusivo o que requer variáveis de ambiente diferentes. Com o
dotenv é possível definir qual arquivo você quer ler, dessa forma conseguimos ter um env para produção/desenvolvimento e outro para testes.O arquivo de produção/desenvolvimento já conhecemos, é o
.env. O para teste você pode definir como .env.testing, e lá definir as chaves e valores normalmente. Com os novos valores.Por fim é preciso fazer o
dotenv saber quando chamar um ou o outro.require('dotenv').config({ path: process.env.NODE_ENV === "test" ? ".env.testing" : ".env" })
Agora para executar seu script como teste, execute da seguinte maneira
NODE_ENV=test node index.js. Dessa forma dissemos ao dotenv pelo path para ele ler o .env.testing.Por padrão a variável
NODE_ENV fica responsável por carregar a informação do estado do seu código:- production: Estado de produção
- development: Estado de desenvolvimento
- test: Estado de teste
E na produção?
Uma dúvida que pode surgir é se esse
.env pode ficar exposto na produção. A resposta é simples, sim ele pode e deve ficar exposto. Sem ele não seria possível o dotenv pegar as informações e jogar para dentro do processo.É subentendido que só acessa a produção quem tem as devidas credenciais, então é preciso ter segurança no acesso do servidor em si. Uma vez acessado pela pessoa errada pode comprometer tudo.
Concluindo
É isso ai DEVS!!
Espero que tenha gostado dessas dicas que com certeza dará mais maturidade aos seus códigos.
Ah, não deixa de compartilhar com seu amigos e qualquer dúvida deixa o comentário ali embaixo.
Tchau.
