Photo by Kevin Ku on Unsplash

Conhecendo o External Configuration Store Pattern: Parte 2 - Criando a API

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