Você também pode verificar o meu artigo em Protobuffers se você estiver interessado em aprender mais sobre eles.
Agora, digamos que precisamos desses dois serviços, que falam protocolos diferentes, para se comunicarem um com o outro.
Podemos criar um middleware que faz uso de uma biblioteca de conversão de dados e traduz as solicitações para um formato que o serviço receptor possa entender.
2) Dados acumulativos-duplicados
A arquitetura de microsserviço é um padrão de arquitetura popular comumente aplicado em aplicativos modernos.
Se você não está familiarizado com a arquitetura de microsserviços, basicamente significa que seu aplicativo consiste em muitos pequenos aplicativos ou serviços que são independentes uns dos outros e operam juntos através da comunicação pela Internet.
Por exemplo, em um projeto de e-commerce, você pode ter um microsserviço para armazenar e recuperar produtos, outro microsserviço para pesquisar e outro para autenticação e armazenamento de usuários. E cada um tem seu próprio banco de dados.
Agora, digamos que desejamos implementar nossa pesquisa de uma forma que busque usuários e produtos.
Se este fosse um aplicativo monolítico, poderíamos simplesmente escrever uma consulta para pesquisar cada tabela e juntar os resultados. Mas agora nossos bancos de dados estão sendo executados em servidores diferentes.
Esse problema tem várias soluções e examinaremos duas delas.
Acumulando dados
Podemos usar um middleware para enviar solicitações a ambos os servidores e solicitar que pesquisem em seus bancos de dados nomes de usuário e produtos que correspondam à palavra pesquisada.
Então podemos acumular os resultados de ambos os servidores e devolvê-los ao cliente. Observe que o número de solicitações aumenta linearmente à medida que aumentamos o número de servidores (e também precisamos mesclar esses dados).
Duplicando dados
Podemos armazenar dados duplicados em nosso servidor de pesquisa para que ele possa pesquisá-los diretamente, em vez de solicitá-los aos servidores de produtos e usuários. Isso é menos eficiente em termos de memória, mas muito mais rápido – e a velocidade é crítica para os serviços de pesquisa.
Se as tabelas de que precisamos são Produto e Usuário, também podemos criar essas tabelas em nosso servidor de pesquisa. Então, sempre que salvarmos um novo usuário em nosso banco de dados de usuários, também salvaremos uma cópia no servidor de pesquisa.
Temos algumas opções: primeiro, podemos chamar os métodos de salvamento do servidor de Pesquisa a partir dos métodos de salvamento dos servidores de Usuário e Produto para duplicar os dados. Ou podemos criar um middleware para salvar, que fará o seguinte:
- Sempre que uma solicitação de salvamento chegar, chame o save do servidor do Produto / Usuário e o save do servidor de Pesquisa.
- Se o primeiro salvamento falhar, não chame o salvamento em outro (isso mantém os bancos de dados consistentes).
Vejamos os diagramas de design sem e com um middleware. Primeiro, é assim que fica sem:
Parece feio, certo? Na verdade, é feio e tornará seu código mais complicado e fortemente acoplado.
Aqui está a mesma solução com um middleware:
Nesse cenário, o lado do cliente apenas chama o middleware para salvar um produto ou usuário e trata do resto.
Não há nenhum código relacionado à duplicação de dados nos servidores do Produto ou do Usuário ou no lado do cliente. O middleware cuida disso.
3) Segurança API
Para qualquer código front-end do lado do cliente, podemos visualizar as solicitações de saída, seja no console do navegador ou por meio de um proxy.
Falamos sobre um servidor de usuários que cuida do login e da inscrição. Se nosso código de front-end enviar diretamente as solicitações para esse servidor, o endereço de nosso servidor de autenticação será exposto. Depois de descobrir o endereço IP de nosso back-end, os invasores podem usar ferramentas para encontrar nossos endpoints e varrer nosso servidor em busca de vulnerabilidades.
Podemos usar middleware como proxy para ocultar a URL do nosso servidor de autenticação. Nosso front end se comunica com o middleware e encaminhará a solicitação para o servidor de autenticação e retornará a resposta.
Essa abordagem também nos permite bloquear todas as solicitações ao nosso servidor de autenticação, exceto as solicitações da URL do nosso middleware. Isso torna nosso servidor de autenticação muito mais seguro.
Isso não era possível anteriormente, porque nosso front end estava se comunicando com o servidor de autenticação. Como o front end significa o computador do cliente, não foi possível aplicar um filtro de IP.
4) Exposição de APIs públicas
Na parte anterior, aprendemos que middlewares podem ser usados para restringir o acesso à nossa API.
Agora, vamos olhar para o outro lado da equação: e se quisermos dar acesso restrito à nossa API? Talvez sejamos engenheiros de software em um banco e o banco esteja planejando um hackathon. Precisaríamos fornecer acesso à nossa API, certo?
Mas, como somos um banco, é claro que não podemos fornecer acesso a toda a API e permitir todas as operações. Isso significa que precisamos encontrar uma maneira de fornecer acesso restrito.
Para este propósito, podemos implementar um middleware que expõe apenas alguns dos endpoints e redireciona as solicitações para a nossa API real. Em seguida, fornecemos essa API aos desenvolvedores do hackathon.
Conclusão
Neste post, começamos definindo o que é middleware e tentamos categorizar os casos de uso de middlewares no desenvolvimento web.
Lembre-se de que esta não é uma lista completa de casos de uso, mas espero que tenha sido útil para você.
Obrigado por ler. Se você gostou do artigo, convido você a conferir meu blog. Você também pode se inscrever em minha lista de e-mails para ser notificado quando eu publicar uma nova postagem 🙂