Photo by Fotis Fotopoulos on Unsplash

Conhecendo o External Configuration Store Pattern: Parte 1 - Contextualizando

Rafael Capuano
Jun 17 · 3 min read

Antes de iniciar um novo projeto, diversas questões técnicas podem vir à nossa mente. Se a ideia é planejar uma aplicação de grande porte, é bom investigar alguns padrões arquiteturais específicos. Um deles é o External Configuration Store Pattern.

Nesta série de artigos, pretendo demonstrar uma implementação inicial dessa ideia baseada em uma aplicação .NET Core. A ideia não é apresentar algo muito complexo, apenas uma introdução ao conceito. Porém, antes de irmos direto ao código, é preciso falar um pouco de teoria, portanto, esse será o foco nessa primeira parte. Então, vamos lá!


External Configuration Store Pattern

Esse conceito se baseia em um repositório único para o armanezamento de quaisquer variáveis relativas à configuração, como por exemplo, uma connection string ou a URL de uma API. Essa ideia é muito útil dentro de uma arquitetura baseada em microservices, por exemplo, onde diversas aplicações podem depender de uma mesma configuração. Para simplificar a comunicação, nesse exemplo, vamos chamar a aplicação responsável pelo armazenamento desses dados de Configuration.

Uma das vantagens de ter um ponto centralizado de acesso é que fica mais fácil lidar com possíveis alterações, seja de um servidor de banco de dados ou ambiente de hospedagem, por exemplo.

A forma de armazenamento dos dados é variada. Pode ser um serviço na nuvem, um banco de dados ou até um arquivo de configuração. Apenas para exemplificar, nesta série vamos utilizar um armazenamento em memória. O importante é que as demais aplicações não devem ter conhecimento sobre isso, elas apenas farão requisições ao Configuration, que terá a missão de retornar os valores.

Porém, se uma única API é responsável por devolver os valores, isso significa que ela será muito requisitada. Devido a isso, uma estratégia de cache é fundamental.

A imagem a seguir exemplifica essa ideia:

Fonte: Microsoft Docs (2017)

Publisher/Subscriber

Seguindo a estrutura apresentada anteriormente, o que deve acontecer se algum valor for modificado? Nesse caso, precisamos atualizar o conteúdo do cache. Para isso, uma possível implementação seria através de um outro pattern bem conhecido: o Publisher/Subscriber.

A ideia consiste em criar um canal de comunicação entre as aplicações. De um lado, temos o publisher, responsável por enviar uma mensagem quando algum evento ocorrer (no nosso caso, sempre que um valor do Configuration for atualizado), a partir de um input channel. Do outro lado, temos as aplicações interessadas nesse evento, que são as subscribers. Elas receberão as mensagens por meio de um output channel.

Um tipo de tecnologia que permite essa aplicação é o message broker. Neste exemplo, foi utilizado o RabbitMQ. A imagem a seguir demonstra o processo:

Fonte: Microsoft Docs (2018)

Autenticação e Autorização

Outro ponto importante diz respeito à segurança. No exemplo a ser apresentado foi utilizado o IdentityServer4, um framework .NET responsável por garantir um acesso autenticado à uma API, que no nosso caso, é o Configuration. Uma vez autenticado, ou seja, quando identificamos quem fez a requisição (client), vem o processo de autorização, isto é, temos que verificar se existe a permissão de acesso (scopes).


Concluindo

Por enquanto vamos ficando por aqui. Vale destacar que tanto o RabbitMQ, quanto o IdentityServer4 possuem conteúdo para muitos outros artigos, mas esse não será o foco desta série. Na próxima parte teremos um pouco de código. Vamos ver a implementação do nosso Configuration usando o .NET Core. Então, até lá!

Referências:

https://docs.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store

https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber

Rafael Capuano

Written by

Analista de Sistemas na Praxio Tecnologia