{A} 1st - API First Strategy
Ao longo da última década, surgiram uma infinidades de paradigmas sobre desenvolvimento de software. Um deles é {A}1st ou API First.
Fazendo uma analogia, quando pensamos em um comércio, nosso objetivo de maior impacto e talvez o mais importante, seja abrir as portas para os clientes, por onde vem o nosso capital, por onde entrarão os produtos a serem vendidos, por onde passarão os funcionários. Então as portas devem estar sempre abertas. Correto?
Então porque não pensar da mesma maneira ao se planejar as aplicações? Nossa aplicação irá expor funcionalidades para outros aplicativos/clientes, certo? Iremos receber informações de outros sistemas ou parceiros, certo?
Mas apenas sair construindo API's, pode se tornar uma tarefa caótica em médio prazo. Para evitar isso, precisamos de planejamento e análise, além de se considerar alguns paradigmas importantes, como:
- Separação de interesses
{A}1st é a separação formal entre o front-end de back-end. Semelhante ao paradigma Model View Controller, desacoplando dados da lógica de apresentação, forçando uma arquitetura de código melhor, o que a longo prazo, diminui a dependência de uma tecnologia, o acoplamento e facilitando enviar dados para várias views, independentemente do tamanho ou funcionalidade. - Especialização
Imagine se para construir uma aplicação web, você tivesse que saber como construir os microchips do zero. Graças à especialização e divisão do trabalho, tudo que você precisa focar é o código. Esta é a vantagem do API First Design. Os desenvolvedores só precisam saber os Requests e as sequências de Responses dos clientes da API. Esta abordagem libera a equipe de desenvolvimento front-end para se concentrar em algumas atividades específicas para interagir com os dados, e a equipe de back-end pode se concentrar em fornecer os dados de uma maneira RESTful. - Modularidade
Por que limitar-se a apenas à uma fonte de dados? Com as práticas modernas de desenvolvimento, você pode facilmente combinar múltiplas APIs para fazer uma poderosa aplicação. E se suas necessidades mudarem, basta adicionar ou remover uma API. Além disso, a abordagem modular facilita a ampliação da sua aplicação.
Além dos benefícios técnicos que a estratégia de {A}1st nos traz, também conseguimos fazer uma melhor separação dos recursos humanos do projeto, já que podemos separar o time em diferentes API's e/ou front-end. Isso otimiza a comunicação entre os times, a manutenção das aplicações, otimizando a entrega.
Em uma próxima oportunidade, falarei sobre como Profissionalizar a entrega de software de maneira ágil e consistente.
--
Lucas Massena
Enterprise Architect
lucas@massena.com.br