fbpx
Minimal API’s e Agnostic Services – Mais reaproveitamento e tolerância à mudanças
Publicado em: quinta-feira, 23 de fev de 2023

As Minimal API’s são uma forma de implementar APIs em .NET, introduzida pela Microsoft no ASP.NET Core 6. Essas API’s são projetadas para serem simples, leves e fáceis de usar, com uma sintaxe concisa que permite criar endpoints de API com menos código.

Hoje quero chamar a atenção para o poder das Minimal API’s quando usadas em conjunto com Agnostic Services, um pattern já abordado aqui no gaGO.io.

Adotar o pattern Agnostic Services pode beneficiar ainda mais a arquitetura da sua aplicação ou serviço.

Neste artigo, discutiremos as vantagens de utilizar minimal API’s em conjunto com Agnostic Services. Também abordaremos os problemas que podem surgir com essas abordagens e o impacto no design, na arquitetura e no negócio.

Leitura Complementar

Sobre Ports and Adapters, Agnostic Services e modelagem de Serviços

Oragon Design Guide – Agnostic Services

O que são Minimal API’s?

Minimal API é uma abordagem para a criação de endpoints de API em .NET.

Em vez de criar um Controller completo com Actions, rotas, injeção de dependência e outras funcionalidades, uma minimal API é definida em uma única função que recebe e retorna objetos.

As rotas são definidas por meio de atributos no método e, em seguida, o método é mapeado para o endpoint de API. As minimal API’s também são mais simples em termos de injeção de dependência e configuração do serviço, tornando-as ideais para projetos menores e equipes que desejam reduzir a complexidade do código.

Mas também são úteis em projetos médios ou grandes em que se quer reduzir a quantidade de responsabilidade da camada web de API’s

O que é Pattern Agnostic Services?

Agnostic Services é um pattern, uma abordagem arquitetural que propõe a separação de conceitos para permitir que os serviços possam ser desenvolvidos com o mínimo possível de conhecimento sobre o padrão arquitetural no qual será utilizado. Em outras palavras, os serviços são independentes de padrões arquiteturais específicos (web, wcf, gRPC, AMQP, desktop, mobile).

Dessa forma, separamos claramente o que é web do que é negócio.

No contexto de uma Web API, cuidamos para não ter código de negócio na Web (API), e para não ter código de Web camada de negócio. Desenhamos um core 100% puro, independente de Web.

Essa abordagem é interessante para projetos que querem poder evoluir sua arquitetura durante o seu ciclo de vida.

Os serviços Agnósticos são projetados para serem independentes da arquitetura, portanto, mais flexíveis e escaláveis.

Eles são capazes de lidar com mudanças e evoluções no projeto sem a necessidade de reestruturação ou refatoração do código. Isso significa que o código é mais fácil de manter e de adaptar às necessidades futuras da aplicação.

Estamos falando de reaproveitamento quase ilimitado, algo que a maioria dos projetos que trabalhamos no dia-a-dia desconhece.

Vantagens da utilização de Minimal API’s em conjunto com Agnostic Services

A utilização de Minimal API’s em conjunto com Agnostic Services pode trazer diversas vantagens para a arquitetura da aplicação, tais como:

1. Independência

A proposta de codificar o serviço de forma pura, sem depender da arquitetura de deployment permite criar serviços que sejam flexíveis o suficiente para serem usados simultaneamente por diversas arquiteturas e estratégias de deployment.

Vamos a um simples serviço de cálculo. Esse serviço poderia ser exposto como Web API, como consumidor de filas AMQP, ou um tópico Kafka, ou como um endpoint gRPC.

Seu código poderia ser um assembly em um nuget privado, e ainda assim poderia ser reaproveitado em qualquer um desses contextos, bastando ao desenvolvedor, criar um wrapper específico para a tecnologia, algo como um proxy que adapter comandos e queries que venham desses provedores para seu agnostic service.

As Minimal API’s são exatamente um desses adaptadores, se usados em conjunto.

1. Maior simplicidade

O uso de Minimal API’s reduz a quantidade de código necessário para criar endpoints de API, o que significa que a aplicação é mais fácil de manter. Além disso, a utilização de Agnostic Services reduz a complexidade do código ao permitir que os serviços sejam desenvolvidos independentemente da arquitetura específica, tornando-os mais simples e flexíveis.

2. Facilidade de manutenção

Com a separação de conceitos proposta pelo Agnostic Services, os serviços se tornam mais fáceis de manter e adaptar às mudanças futuras.

Isso significa que as alterações no projeto podem ser realizadas com menos esforço e risco, pois os serviços são independentes da arquitetura e podem ser alterados sem afetar o restante da aplicação.

Além disso, a utilização de Minimal API’s reduz a quantidade de código necessário para implementar os endpoints de API, o que significa que a manutenção é mais fácil e menos propensa a erros.

3. Maior adaptabilidade

Com a separação de conceitos do Agnostic Services, os serviços se tornam independentes da estratégia de exposição e deployment. Sendo possível embarcá-los em qualquer lugar, com o máximo de reaproveitamento.

Isso significa que os serviços podem ser reutilizados em diferentes arquiteturas e plataformas, o que entrega poder e flexibilidade para arquitetos e desenvolvedores.

4. Maior produtividade

A utilização de Minimal APIs e Agnostic Services pode melhorar a produtividade da equipe de desenvolvimento. Com a sintaxe concisa das Minimal APIs e a separação de conceitos do Agnostic Services, a equipe pode se concentrar em desenvolver serviços de alta qualidade em menos tempo.

Isso pode permitir que a equipe entregue mais recursos em menos tempo, aumentando a produtividade geral do projeto.

5. Facilidade de teste

A utilização de Minimal API’s torna os endpoints de API mais fáceis de testar, pois há menos código para ser testado. Além disso, a utilização de Agnostic Services pode permitir que os serviços sejam testados independentemente da arquitetura, o que pode tornar os testes mais fáceis e menos propensos a erros.

Ports and Adapters / Hexagonal

A Ports and Adapters separa a lógica de negócio do domínio da aplicação das implementações técnicas, como bancos de dados, frameworks, bibliotecas, etc. Isso é alcançado por meio da criação de portas (interfaces) que representam as funcionalidades do domínio, e de adaptadores que conectam as implementações técnicas às portas.

A abordagem permite que as implementações técnicas, tecnológicas, sejam implementadas distante da lógica de negócio, o que de certa forma já entrega um aspecto agnóstico para a lógica de negócio.

Agnostic Services se encaixa com uma luva nessa arquitetura, pois propõe a separação de conceitos para permitir que os serviços possam ser desenvolvidos com o mínimo possível de conhecimento sobre o padrão arquitetural utilizado.

Com o Agnostic Services, a lógica de negócio também é separada das implementações técnicas da mesma forma que na Ports and Adapters, facilitando a substituição de implementações técnicas sem afetar a lógica de negócio.

Além disso, a separação de conceitos proposta pelo Agnostic Services pode ser vista como uma evolução dos Application Services do Ports and Adapters.

Enquanto a Ports and Adapters propõe a separação das implementações técnicas do domínio da aplicação, o Agnostic Services propõe a separação do padrão arquitetônico do domínio da aplicação.

Com o Agnostic Services, os serviços podem ser desenvolvidos independentemente da arquitetura específica que será utilizada, o que aumenta ainda mais a flexibilidade e a capacidade de reaproveitamento da lógica de negócio, que assume uma característica altamente portável entre arquiteturas.

Agnostic Services se encaixa bem na Ports and Adapters e em outras arquiteturas que propõem a separação de conceitos para aumentar a flexibilidade, reaproveitamento, testabilidade e a manutenibilidade da aplicação.

Problemas que podem surgir com a utilização de Minimal APIs em conjunto com Pattern Agnostic Services

Embora a utilização de Minimal APIs em conjunto com Agnostic Services possa trazer muitos benefícios para a arquitetura da aplicação, existem alguns problemas que podem surgir.

1. Complexidade de design

Embora a utilização de Minimal API’s reduza a quantidade de código necessário para criar endpoints de API, isso pode tornar o design da aplicação mais complexo. Isso ocorre porque as funcionalidades que costumavam estar na Controller agora são delegadas para uma camada agnóstica que não pode depender de características de web.

Isso torna o design puro, e fácil de entender, mas inevitavelmente torna também mais complexo e aumenta, mesmo que pouco, a curva de aprendizado.

2. Reutilização de código

A utilização de Agnostic Services pode tornar os serviços mais flexíveis e reutilizáveis, mas isso pode exigir que o código seja escrito de uma forma mais genérica. Isso pode tornar o código mais difícil de entender e pode aumentar a complexidade.

Impacto na arquitetura e no negócio

A utilização de Minimal API’s em conjunto com Agnostic Services pode ter um grande impacto na arquitetura e no negócio da aplicação.

1. Arquitetura

A utilização de Agnostic Services pode permitir que a aplicação seja mais flexível e escalável, permitindo que os serviços sejam reutilizados em diferentes arquiteturas e plataformas. Além disso, a utilização de Minimal API’s pode tornar a aplicação mais simples, o que pode melhorar a eficiência e a manutenibilidade da arquitetura.

2. Negócio

A utilização de Minimal API’s em conjunto com Agnostic Services pode ter um grande impacto positivo no negócio. Com a aplicação mais flexível e escalável, a equipe de desenvolvimento pode se concentrar em fornecer funcionalidades com alta qualidade em menos tempo, o que pode aumentar a eficiência geral do projeto e ajudar a empresa a alcançar seus objetivos de negócios.

Além disso, a utilização de Minimal API’s e Agnostic Services pode permitir que a equipe de desenvolvimento se concentre mais em desenvolver funcionalidades importantes para a aplicação, em vez de se preocupar com a complexidade da arquitetura. Isso pode permitir que a equipe entregue mais valor para o negócio da aplicação.

Conclusão

A utilização de Minimal API’s em conjunto com Agnostic Services pode trazer muitos benefícios para a arquitetura e o negócio da aplicação. Embora existam alguns problemas que podem surgir, os benefícios superam amplamente as desvantagens.

Com a utilização de Minimal API’s, a aplicação se torna mais simples e leve, o que pode melhorar a eficiência e a manutenibilidade. Além disso, a utilização de Agnostic Services torna os serviços mais flexíveis e reutilizáveis, o que pode facilitar a escalabilidade da aplicação.

No geral, a utilização de Minimal API’s em conjunto com Agnostic Services é uma abordagem que deve ser considerada em projetos que buscam melhorar a eficiência, a manutenibilidade e a escalabilidade da arquitetura, bem como melhorar o valor entregue para o negócio da aplicação.

Próximos passos

Agnostic Services é o meio que usamos no Cloud Native .NET para tornar serviços independentes e altamente reaproveitáveis. É dessa forma que um mesmo serviço, sem nenhuma necessidade de manutenção, nem mínima, é reaproveitado como Consumidor de Filas AMQP, Endpoint HTTP para Web API, embarcado em memória como uma classe que instanciamos.

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.