Desacoplamento em APIs com API First

8 min readMar 6, 2020

Introdução

Não preciso falar para ninguém o quanto os valore e princípios de SOA influenciaram a minha vida.

Caso vocês não tenham acompanhado a série em SOA que escrevi, segue:

Como dito no primeiro artigo, quando fui adentrar ao mundo de SOA eu pensava que isso era um JAR, mais ou menos como o AspectJ é para Orientação à Aspectos. Na minha cabeça era tudo Tecnologia e Programação.

Todas essas primeiras impressões vocês podem acompanhar pelos artigos, mas a fim de aprofundar um pouco mais a história, gostaria de compartilhar com vocês a pessoa que me tirou da minha ignorância de que o Java resolveria tudo, o homem, a lenda, o mito Valério Aymoré Martins.

Valério é esse cidadão mais à direita, e foi ele quem me ajudou nos meus primeiros passos com a Arquitetura Orientada a Serviços, em um instituto de pesquisa conhecido como Instituto de Brasília de Tecnologia e Inovação, o IBTI.

Depois desse contato com SOA, incuti tanto na minha cabeça que o desacoplamento entre camadas de serviço era bom, que eu tive dificuldades para adentrar em um mundo diferente do SOAP, o REST.

Desacoplamento de camadas de serviço

O problema da minha transição não foi SOA ou sequer o SOAP, na verdade eu era um desenvolvedor Java Pleno à época, porém, era apenas um desenvolvedor SOA Jr.

Quando aprendi sobre Contract-First e suas vantagens, era como se tudo para mim tivesse que se encaixar naquela premissa. Não me interessava então se eu conseguia fazer uma API REST de forma fácil com NodeJS ou Spring Boot, se não desse para fazer Contract-First não servia.

Na verdade eu era muito Jr para perceber que eu estava perdendo várias coisas e evoluções em REST dado essa minha imaturidade.

O início dessa história vocês podem ver aqui com meu relato sobre o RAML, e aqui, quando iniciei minha jornada com o Swagger.

Não vou entrar muito no mérito de se eu concordo que REST deve ou não sempre seguir uma abordagem API First, mas gostaria de compartilhar com vocês um cenário em que temos visto que API First se encaixar muito bem, Jornada do cliente.

Jornada do cliente

Trabalhei no IBTI, e posteriormente na Core Consulting, ambas empresas com SOA, e não poderia deixar de mencionar outra pessoa que me influenciou muito principalmente em questões de soft skills, André Toffanello. Graças ao viés mais técnico do Valério com uma visão fora da caixa do Toffanello eu pude iniciar minha mentalidade com o que SOA define como Alinhamento do negócio com a TI!

Isso me ajudou depois na AIS Digital com pessoas como Isaac Canan e Rafael Lucyk em propor ideias a serem trilhadas e novas propostas para gerar inovação, buscando autonomia e podendo discutir pontos de vista que não são algo como uma pessoa manda e você obedece! Sobre a AIS, ainda pretendo escrever outro post um dia. Voltemos a SOA e jornada do cliente.

Contract-First e API First sempre foram coisas que eu tinha um apreço muito grande, dado que como sempre trabalhei com backend, eu via nisso uma grande vantagem em desacoplamento, e possibilidade de poder desenvolver coisas como mock seguindo o contrato proposto, com isso, o peso sobre a equipe de backend diminuia.

Porém, algo que sempre esteve lá, e que eu só consegui enxergar trabalhando em uma empresa de tecnologia especializada em produtos digitais foi: era possível aproximar o contexto funcional e granularidade dos meus serviços, bem como sua governança, se eu me aproximasse de uma equipe que nunca pensei que me aproximaria um dia, a equipe de UI, UX e Design.

API First, UI, UX e Design, como eu nunca tinha enxergado isso?

Se você quiser conversar com alguém que tenha apreço por serviços em uma Arquitetura Orientada a Serviços aqui vão alguma palavras que podem fazer você ganhar pontos com ele: granularidade, governança, autonomia, composição, dentre outras.

Uma das maiores dificuldades para profissionais dessa área é o tamanho do grão que um serviço deve ter para ser considerado o mais agnóstico possível, trazendo mais Retorno de Investimento (ROI).

Quando falamos de serviços agnósticos estamos falando de serviços que podemos utilizar em vários contextos em composições de serviços, sendo assim, não são focados em um cenário específico.

Trabalhei em um projeto na AIS em que a equipe de UI, UX e Design me ajudaram a perceber que eles tem um papel muito importante junto ao cliente com o grão de uma parte das minhas APIs.

Seguindo os dois desenhos é possível notar as camadas que são mais ou menos agnósticas, bem como as camadas que estão mais próximas aos processos e jornada do cliente.

Na AIS começamos a fazer uma coisa bem interessante, colocar pessoas com capacidade de especificar APIs juntos à pessoas que estão desenhando jornadas atuais e novas do cliente.

UI, UX e Design e modelos Top-Down e Bottom-Up

E como modelos Top-Down ou Bottom-Up influenciam isso?

Quando estamos falando de soluções com aplicações legadas, o profissional que especifica APIs pode levantar dificuldades com a equipe de UI, UX e Design na concepção de alguns protótipos de tela, mostrando que talvez não seja possível alcançar o máximo da usabilidade e experiência do usuário dado o legado existente, sendo direcionado assim uma abordagem Bottom-Up.

Já em cenários green field podemos direcionar para inovações e abstrações que direcionem a jornada.

Tanto em cenários Top-Down quanto em cenários Bottom-Up, nós como especificadores de APIs em uma abordagem API First desejamos o que? Que quando o desenvolvedor frontend ou o banckend forem dar vida às definições de prototipação não tenhamos surpresas do tipo: “ah, essa tela não vai poder ser implementada assim, porque o nosso backend não comporta”

Tá, mas e o código?

Não sei se foi Linus Torvalds quem disse essa célebre frase, como diria a máxima, “se está na internet é verdade”, mas, sei que você desenvolvedor que está me acompanhando deve estar achando que eu estou te enrolando, afinal, eu havia dito antes que iria falar nesse post sobre implementação do projeto que já está no meu GitHub.

Achei interessante alinhar essas questões negociais antes, pois percebo que quanto mais nos distanciamos do negócio, menos nos valorizamos e menos as pessoas enxergam o impacto das nossas ações nos produtos e jornadas, mas vamos começar a discutir alguns pontos mais técnicos para dar um direcionamento sobre o que falaremos no próximo post, esse mais técnico, dessa vez eu prometo.

Qual banco eu uso em API First?

Um dos erros que mais vemos em se tratando da jornada do usuário somos nós como desenvolvedores já iniciarmos nesse ponto as definições sobre SQL ou NOSQL, como me conectar com a coluna X, Y, Z, e outras coisas que acoplam.

O ponto é que, se nós já começarmos a olhar e direcionar nossas APIs em uma estratégia em API First com o nosso banco de dados, naturalmente estaremos atrapalhando a jornada do cliente, pois estaremos limitando o cliente a uma experiência de algo realizado há sei lá, cinco, seis, dez anos ou mais, e seria muito complicado acreditar que aquela modelagem esteja completamente alinhada com uma jornada que vamos fazer agora.

Em uma abordagem digital, acreditamos que o cliente está no centro!

Falaremos mais sobre isso no próximo post, porque temos uma outra máxima: “Nãos dá para ganhar tudo”, para obter o desacoplamento do contrato com o backend acabaremos precisando desacoplar as camadas de modelo da API com as camadas de modelo que utilizamos para persistir dados.

Outro ponto interessante, é que às vezes teremos que diminuir a experiência do cliente em detrimento aos nosso legados, porém, isso não deve ser o ponto de partida, essa é a ideia.

Acho bem interessante uma palestra que vi no APIX 2019 em que o Kleber Bacili, CEO da Sensedia, uma parceira da AIS e representante brasileira no Gartner e Forrester Wave na categoria de API Manager. Nela o Kleber diz que apesar de a Sensedia possuir um conector em se integra diretamente com um banco de dados, isso acaba trazendo um acoplamento que podemos não querer ligar diretamente com nossa camada de exposição de APIs.

Por falar em APIX as inscrições para o desse ano já estão abertas, corre lá.

Sobre os eventos anteriores, vocês também podem ver no próprio canal da Sensedia as playlists em português e em inglês do ano passado.

E por falar em apresentação, nós da AIS Digital também estivemos lá, e vocês podem conferir os norteadores que direcionaram esse artigo, eu e o Samuel Corado falamos sobre a Transformação de sua estratégia de canais com APIs:

Nos vemos no próximo post para falar de OpenAPI 3.0 com Spring Boot, Maven, Gradle e Kotlin… até lá…