Carga de variáveis de configuração de uma aplicação thrust.

[Brunomachadob]

Gostariamos de criar um mecanismo que realiza a leitura de variáveis de configuração da plataforma a partir de diferentes sources, que seja de fácil configuração e utilização.

Dado o seguinte exemplo:

var server = require('http');
var router = require('router');

server.createServer(env('port'), router)

Gostariamos que a função env, por exemplo, consiga carregar esta informação de porta de várias fontes diferentes, de forma ordenada e com ordem de prioridade.

Até então pensamos em três fontes: config.json, environment e cmd arguments.
Segue abaixo os exemplos de utilização das três formas citadas, com base no exemplo acima:

config.json

Arquivo que já utilizamos hoje que pode conter várias configurações da aplicação e bibliotecas utilizadas.

{
    "port": 8778
}

environment

Utilizar o env da máquina para configuração de informações.

export port=8778
thrust startup.js

argumentos

Nova forma de passagem de parâmetros que estamos avaliando para o thrust v5.

thrust startup.js -port 8778

Com base nestas informações, gostariamos de levantar a discussão em relação as possíveis fontes (se devemos incluir/remover alguma) e da ordem de prioridade das mesmas.

Imagine, que em um determinado momento utilizamos as três fontes citadas acima, ou seja, temos o arquivo, fizemos export no env, e também passamos port como argumento.
Qual deve ser a prioridade das fontes?

Iniciamente eu e o @cneryjr discutimos e consideramos que os argumentos de linha de comando devem ser os de maior prioridade.

Como segundo e terceira ordem de prioridade, tivemos pensamentos divergentes e gostariamos de discutir aqui para que consigamos elaborar um sistema inteligente e que reflita bem todo o fluxo do desenvolvimento, desde o startup com o arquiteto até as fases de deploy em hml e produção.

[Brunomachadob]

Minha opinião é:

1º: argumentos de comando

Argumentos passados via linha de comando devem ser sempre prioritários em relação a qualquer outra configuração.

2º: env

Caso uma variável não foi localizada nos argumentos de comando, então devemos pesquisar no env da máquina onde a aplicação está rodando.

3º: config.json

Por último, olhamos o arquivo estático, ou seja que não é alterado por ninguém durante o fluxo de desenvolvimento.

Nesse arquivo podemos ter algumas informações estáticas que nunca mudam de acordo com ambientes e etc, como por exemplo configuração de rotas e afins.

Porta, poderiamos deixar uma padrão no arquivo de configuração, mas caso passado via argumento, seria utilizada a do argumento.

Informações sensitivas como senha, poderia ser passada como env.

Dessa forma fica fácil para que em qualquer momento variáveis de execução possam ser alteradas sem depender da alteração do fonte (config.json) alterando apenas ou via linha de comando para variáveis não sensitivas e env para variáveis sensitivas.