Uma abordagem de desenvolvimento API-First

Independentemente do tipo de aplicativo desenvolvido, eles são quase sempre pensados para a nuvem, sendo o objetivo final fazer com que o APP se torne parte de um ecossistema de serviços. Neste contexto, uma abordagem API-First merece uma análise aprodundada.

O que é API e para que serve?

API significa Interface de Programação de Aplicações, o acrônimo API corresponde às palavras em inglês “Application Programming Interface” e serve para integrar sistemas independente da linguagem de programação, proporciona uma troca de informações de forma muito segura.

Porque usar APIs-REST

A economia das APIs está crescendo rapidamente e as empresas também estão aderindo à ideia de tornar as APIs parte integrante de suas estratégias de crescimento.

Gigantes da tecnologia como Apple e Google, por exemplo, têm orientado seus sistemas para um futuro centrado em APIs. A interface dos novos hardwares interconectados, wearables e em breve dos carros sem motorista mostram como as APIs são importantes em nossas vidas.

O que é API-First?

Muitas empresas começam com a construção de apps web ou apps para dispositivos móveis e só então, como um projeto paralelo, criam uma API para empresas terceirizadas ou para fins de integração. Essas organizações vêem a questão como dois canais: um canal web ou mobile e um canal de API. O problema com essa abordagem é que resulta em uma API artificial que não foi devidamente construída e testada ao longo do projeto.

Uma abordagem mais recomendada é desenvolver primeiro uma API e construir a web ou apps mobile em cima dessa API. Isso obriga o desenvolvedor a projetar uma API e usá-la para seu próprio aplicativo para que se torne uma API REST mais próxima do mundo real e compatível com o desenvolvimento de produto ou serviço.

O desenvolvimento API-First é uma estratégia em que a primeira ordem de negócio é desenvolver uma API que coloque os interesses do desenvolvedor de destino em primeiro lugar para somente, em seguida, construir o produto em seu topo – seja um site, aplicativo móvel ou um software SaaS. Ao construir em cima de APIs tendo os desenvolvedores em mente, muito esforço de trabalho é poupado ao se estabelecer as bases onde outros desenvolvedores irão construir seus apps.

Para simplificar, pense no contexto todo da seguinte forma: você está criando aplicativos nativos na nuvem. Após o código ser verificado em seu repositório, os testes são executados automaticamente e release candidates são executados em um ambiente de laboratório em poucos minutos.

Agora, outra equipe na sua organização começa a criar serviços com os quais seu código interage. E então, outra equipe (ainda) se empolga e resolve começar a desenvolver em conjunto com as equipes anteriores. Em pouco tempo, existirão várias equipes construindo serviços com dependências horizontais em uma cadência de liberação diferente diferente da outra. O que pode acontecer se nenhuma disciplina for aplicada ao contexto acima descrito, será um verdadeiro pesadelo em termos de integração.

Para evitar falhas no processo de integração e reconhecer formalmente a API como um artefato de primeira classe no processo de desenvolvimento, a abordagem API-First dá às equipes a capacidade de trabalhar uns com os outros sem interferir nos processos internos de desenvolvimento.

Mesmo quando não há um planejamento para construir um serviço como parte de um ecossistema maior, a disciplina de iniciar todo o desenvolvimento em nível de API ainda é válida para poupar muito trabalho e tempo.

Porque API-First?

Atualmente, um processo de desenvolvimento não é paralelo, mas síncrono. Uma vez que um novo serviço ou recurso comece a ser desenvolvido, as equipes pesquisa e desenvolvimento já começam a trabalhar no projeto. Uma vez feito, a equipe de backend começa a escrever um protótipo – outras equipes, como as de frontend e de Q&A estão no aguardo. Uma vez que o protótipo tenha sido concluído, um documento da API pode ser preparado e compartilhado com as diferentes equipes (Q&A e de frontend).

Quando a mudança é necessária por conta de um recurso, bug, melhoria ou aprimoramento, este ciclo começará novamente, desperdiçando um tempo de desenvolvimento valioso e com isso possivelmente atrasando o lançamento do novo serviço para o mercado.

Como podemos ver na imagem acima, em primeiro lugar, a equipe backend está começando a desenvolver e implementar uma nova API. Em seguida, a API está sendo repassada às equipes frontend e de testes para usá-la e testá-la. Na sequência, as equipes equipes frontend e de testes estão construindo SDKs, testes e muito mais para interagir com a API. Este é o desenvolvimento síncrono.

Sendo assim, a abordagem API-First permitirá o desenvolvimento paralelo por todas as equipes sem a necessidade de esperar por alterações para ser finalizado por uma equipe ou outra.

Na imagem acima, podemos ver que as APIs criadas são mocks (simulações). E que as equipes de backend, frontend e de testes estão começando a trabalhar com as APIs simuladas. Quando a API estiver pronta, todas as equipes podem alternar para a API de produção ou de teste. Um cenário que economiza muito tempo de desenvolvimento.

O RestCase fornece ferramentas para simulação (mocking), debug, documentação automatizada e de teste para APIs, com notificações entre equipes e compartilhamento em todas as etapas de projeto e desenvolvimento, além de possibilitar uma abordagem de API-First.

Criando serviços API-First

Atualmente, o conceito de “mobile first” está ganhando muita tração. Refere-se à noção de que, desde o início de um projeto, tudo o que é feito gira em torno da ideia de que o que é construído é um produto a ser consumido por dispositivos móveis. Da mesma forma, API-First significa que o que é construído é uma API a ser consumida por aplicativos de cliente e serviços.

“Cloud-native” é mais do que apenas uma lista de regras ou diretrizes. É uma filosofia e, para muitos desenvolvedores, um modo de vida. Como tal, existem diretrizes cloud-native que podem não necessariamente mapear requisitos físicos específicos impostos pela nuvem, mas que são de vital importância para os hábitos de pessoas e organizações que desenvolvem aplicações modernas, que por sua vez estarão prontas para futuras alterações no cenário de nuvem.

Construir sob cada decisão tomada e em cada linha de código escrita é a noção de que todos os requisitos funcionais da aplicação serão atendidos através do consumo de uma API. Mesmo uma interface de usuário, seja web ou mobile, nada mais é do que o consumo de uma API.

Ao optar pela API-first, o desenvolvedor pode facilitar a discussão com seus stakeholders (equipe interna, clientes ou possivelmente outras equipes dentro da organização que desejam consumir a API) bem antes de ter codificado para além do ponto de retorno. Essa colaboração permite criar histórias de usuários, fazer o mock da API e gerar documentação que pode ser usada para socializar ainda mais a intenção e a funcionalidade do serviço que está sendo criado.

Atualmente existem inúmeras ferramentas e padrões para suportar o desenvolvimento API-First. Existe um formato padrão para especificação de API que usa uma sintaxe do tipo markdown chamada API Blueprint ou Swagger. Esses formatos podem ser usados por código para gerar documentação e até mesmo mocks de servidor REST API, que são inestimáveis para testar os ecossistemas de serviço.

Em outras palavras, não há absolutamente nenhuma desculpa para afirmar que API-First é um caminho difícil ou não suportado. Este é um padrão que pode ser aplicado ao desenvolvimento de software não orientado à nuvem, mas é particularmente bem adaptado ao desenvolvimento da nuvem em sua habilidade de permitir prototipagem rápida, suportar um ecossistema de serviços e facilitar os testes de deploy automatizados e pipelines de entrega contínua que são algumas das características do moderno desenvolvimento de aplicativos nativos da nuvem.

Essa abordagem é uma extensão do padrão de desenvolvimento contract-first, onde os desenvolvedores se concentram inicialmente na construção da estrutura de aplicação. Com os pontos de integração testados continuamente por meio de servidores de integração contínua, as equipes podem trabalhar em seus próprios serviços e ainda manter garantias razoáveis de que tudo funcionará corretamente.

O API-First liberta as equipes de desenvolvimento do velho esquema waterfall, sistema deliberadamente projetado que segue um padrão de orquestração pré-planejado e permite que os produtos evoluam em ecossistemas orgânicos e auto-organizados que podem crescer para lidar com novas e imprevistas demandas.

Conclusão

Em uma construção monolítica – ou até mesmo um ecossistema monolítico – que interaje de forma fortemente acoplada, a capacidade de se adaptar a novas necessidades ou criar novos consumidores de recursos existentes é dificultada. Por outro lado, ao se adotar a mentalidade de que todas as aplicações são apenas serviços de apoio, e que devem ser projetadas em uma abordagem API-first, o sistema estará livre para crescer, adaptar-se a uma nova carga e demanda e acomodar novos consumidores de serviços existentes sem precisar parar o mundo para rearquitetar um sistema fechado.

Fonte: DZone.com

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.