Gerenciando variáveis ambiente no NodeJS

Node.js 10 de Jan de 2019

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 trim na string;
Pode existir chave sem valor, que retorna uma string vazia;

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.