Photo by Kevin Ku on Unsplash
Rafael Capuano
Jun 17 · 3 min read

Na primeira parte desta série, discutimos alguns conceitos que são base para a implementação da nossa versão do External Configuration Store Pattern, chamada de Configuration. Agora é hora de código! Os exemplos apresentados foram desenvolvidos utilizando um projeto .NET Core.


Criando a API do Configuration

A estrutura básica para representar os valores de configuração é apresentada a seguir, por meio da classe ConfigurationModel. Não há muito segredo aqui, uma chave identifica um valor correspondente:

Para retornar as informações pelo controller, foi criada a classe ConfigurationResponse:

A interface IConfigurationStore apresenta a estrutura básica para gerenciarmos os valores configurados:

A seguir, temos a implementação. Como comentado na primeira parte, apenas para exemplificar, os valores são armazenados em memória, por meio da classe Dictionary do C#. Em uma aplicação real, podemos utilizar um serviço na nuvem, um banco de dados ou até um arquivo de configuração. Porém, o princípio é o mesmo, o importante é encapsular a lógica no Configuration, para que as demais aplicações não dependam do mecanismo utilizado.

Durante a criação da classe, o dicionário de dados é criado, atribuindo uma URL fictícia para a chave de identificação API_URL. Além disso, temos um método Obter(), que busca o conteúdo no dicionário:

Para que os valores possam ser atualizados, temos a implementação do método Salvar(), que verifica se a chave que identifica a variável de configuração foi informada. Se estiver tudo certo, o valor é atualizado e na sequência publicado por meio do RabbitMQ, que conforme vimos antes, repassa o novo valor a todos os clientes dessa aplicação (posteriormente, criaremos um deles).

Neste exemplo, temos um servidor local com o RabbitMQ instalado. O método Publish() representa um exemplo de como enviar uma mensagem para todas as aplicações subscribers. Para tanto, foi instalado o NuGet RabbitMQ.Client, além do Newtonsoft.Json, que auxilia na serialização do nosso objeto a ser enviado.

Na classe Startup temos a configuração do IdentityServer4, sendo que a URL do seu servidor é retornada através de um appsettings.json, acessada pela variável AUTHORITY_URL. Ficou definida uma política de autorização, para não deixarmos a rota exposta. Como podemos notar, nossa API requer um token com acesso ao escopo API_CONFIGURATION, que deve ser enviado no header do request HTTP. Para isso, foi instalado o NuGet IdentityServer4.AccessTokenValidation:

Outro detalhe importante que pode ser percebido é a definição de que a classe ConfigurationStore deve ser injetada como um singleton, já que nesse exemplo, os dados estão armazenados em memória, então, para simular uma alteração, onde o valor atualizado deve ser retornado em um futuro Get, é preciso que a mesma instância seja utilizada a cada requisição para nossa API.

A implementação do ConfigController é apresentada a seguir, contendo os métodos Get() e Put(), que executam o nosso ConfigurationStore:


Concluindo

Bom, isso completa nossa implementação inicial do Configuration. Na parte final desta série, teremos a criação de uma aplicação cliente, que fará as requisições e terá um gerenciamento de cache dos valores retornados.

Então, até a próxima!

Rafael Capuano

Written by

Analista de Sistemas na Praxio Tecnologia — Um apaixonado por programação, fã de futebol, movido pelo desafio de viver…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade