Você precisa de uma API?

Nos últimos anos tenho advogado em prol do API-First. Não apenas por acreditar nos impactos econômicos que a prática pode apresentar, como também nos benefícios de arquitetura, organização e integração. Sem falar no "supracitado" Developer eXperience, que vem quase que embutido ao realizar o design de suas APIs antes mesmo de implementá-las.

• O API-First
• API-First: Processo e ferramentas
• API Blueprint: Markdown é vida!
• Swagger e o Open API Initiative
• Swagger na prática
• Ramilificando as suas APIs

Como nem tudo em desenvolvimento pode ser considerado "bala de prata" (estou olhando para você, microservices), o propósito desse artigo é estressar a motivação por trás da construção de uma API.

O que é uma API?

Segundo Tyler Elliot:

In general, APIs define the rules that programmers must follow in order to interact with a programming language, a software library, or any other software tool. Lately though, the term API is most often used to describe a particular kind of web interface. These Web APIs are a set of rules for interacting with a webserver (such as a Salesforce server), with the most common use case being data retrieval.

Em outras palavras, você acessa o Gmail diariamente do seu browser através da interface web. Porém, integrações com outras máquinas são realizadas através de APIs.

Na verdade, mesmo o Gmail aberto em seu navegador depende de APIs para funcionar. Possivelmente as mesmas APIs que alimentam a app mobile do próprio Google, ou clientes terceiros (como o Mail, da Apple).

Mashup, SaaS, e economia

E o primeiro argumento gira em torno dessa oportunidade de integrações e negócios com terceiros.

O termo Mashup ganhou popularidade após a Web 2.0 (entreguei a idade nessa referência) transformar a forma como a web era desenvolvida. Mashups são APIs, websites ou serviços que misturam diferentes fontes afim de entregar uma solução. Um bom exemplo de mashup é a interface de busca do Airbnb, integrada ao Google Maps.

Integrações com terceiros fazem parte do cotidiano dos desenvolvedores web, e não é raro tais integrações se materializarem na forma de APIs. Além disso, o conceito de "Software Como Serviço" (SaaS) está amplamente estabelecido no mercado, e há uma certa expectativa que o seu produto possua algumas de suas características.

Oras! Você já é um desenvolvedor web, desenvolvendo para a nuvem. O que te custa fazer disso um serviço e disponibilizar alguns endereços para que um cliente conecte-se com a sua solução?

E aqui é possível enxergar que além da técnica em relação à integrações, há um fator econômico que precisa ser levado em consideração. Jennifer Riggins, no How To Design Great APIs With API-First Design, explora um pouco mais dessa vertente. Mas uma das melhores definições vem do pessoal da MuleSoft:

The innovative power of APIs has led to the realization that APIs can be a critical component of enterprise solutions that impact the operational bottom line, contributing to efficiencies, growth, and innovation. That, in turn, has created the API economy, which is loosely defined as the way APIs can positively affect an organization's profitability.

Portanto, se você estiver construindo um produto onde tais integrações podem ser um novo canal de distribuição (ou até mesmo o principal canal de distribuição), ter uma API faz todo o sentido.

Em contrapartida...

Embora seja de conhecimento público que a Netflix utilize microsserviços (e os serviços possuam APIs para uso interno), a "locadora vermelha" não possui API pública (até o momento da escrita desse artigo). E esse exemplo pode servir como argumento para ilustrar que nem tudo precisa ser concebido com uma ideia de integração desde o seu princípio.

No entanto, assim como no exemplo do Gmail, para entregar um conteúdo de forma coesa para tantos clientes diferentes (TV, mobile, web, etc), há uma necessidade técnica que fortalece o argumento do uso de protocolos de comunicação.

Front-end x Mobile x Back-end

No caso do Gmail, por exemplo, o protocolo POP seria o suficiente para conectar um cliente com o servidor, afim de ler os e-mails. Ao falarmos de soluções web, e portanto, funcionando sobre a camada HTTP, esse tipo de interação é comumente efetuada através de APIs REST.

Há nem tanto tempo atrás, full-stack developers eram comuns no mercado de desenvolvimento web. Soluções eram basicamente HTMLs sendo entregues com a interface tendo apenas intervenções de Javascript para enriquecer a experiência.

Com os navegadores evoluindo cada vez mais, as interfaces web ficando cada vez mais complexas, e demandas nos domínios de front-end e back-end exigindo maior especialidade; Hoje o padrão de mercado é encontrarmos desenvolvedores especializados em front-end, ou em back-end, ou até mesmo mobile.

Full-stack developers são considerados "unicórnios", e por mais que eu tenha passado a maior parte da minha carreira como um, admito que hoje em dia é muito difícil ficar nessa posição e manter-se atualizado com as novidades e tendências (principalmente no mercado front-end).

Portanto, é bem provável que o time de front-end do seu projeto adote React ou Vue.js, e demande do time de back-end algumas APIs (REST ou não) para que possam entregar conteúdo dinâmico ao usuário final. É certo que essa demanda acontecerá se, por exemplo, o seu produto tiver uma versão mobile nativa.

Em contrapartida...

Há um debate em torno de especialidades e do papel de um full-stack. David Humphrey sugere que nessa condição, deveríamos ser capazes de "subir ou descer", e oferecer ajuda, independente da expertise em cada nível de uma stack:

(...) is not about becoming an expert at every level of the stack. Rather, its goal is to erase the boundary between the levels such that you can reach up or down in order to offer help, even if that help is only to offer a kind word of encouragement when the problem is particularly hard: these are our problems, after all.

Outro argumento gira em torno do excesso de complexidade que virou desenvolver (qualquer coisa) para a web.

Com um time multidisciplinar, é possível que você não precise confiar em uma API para conectar as duas especialidades, e com o bom e velho modo de fazer web (por exemplo, Django entregando HTML) seu time seja capaz de entregar um produto (ainda assim) interessante.

Só para não parecer um post "anti-SPA" ou "anti-React", faço das palavras de Tom MacWright as minhas:

I don’t think that everyone’s using the SPA pattern for no reason. For large corporations, it allows teams to work independently: the “frontend engineers” can “consume” “APIs” from teams that probably work in a different language and can only communicate through the hierarchy. For heavily interactive applications, it has real benefits in modularity, performance, and structure. And it’s beneficial for companies to shift computing requirements from their servers to their customers browsers: a real win for reducing their spend on infrastructure.

Se você acha que sua empresa ou produto não se encaixa nos critérios levantados na citação a cima, HTML renderizado no server side, com pitadas de Javascript, ainda é uma realidade.

Microservices

Microservices foi uma das ondas que sacudiu o mundo do desenvolvimento back-end recentemente. O conceito de computação distribuída não é novo, mas com a popularização de ferramentas como Kubernetes e Docker, fica difícil resistir à tentação de mover toda uma solução para microsserviços.

O portal da Red Hat define a arquitetura da seguinte forma:

Microsserviços são uma abordagem de arquitetura para a criação de aplicações. O que diferencia a arquitetura de microsserviços das abordagens monolíticas tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é denominada um serviço e pode ser criada e implantada de maneira independente. Isso significa que cada serviço individual pode funcionar ou falhar sem comprometer os demais.

As vantagens são numerosas, dentre elas:

• Habilidade de escalar horizontalmente qualquer um de seus componentes;
• Serviços são independentes. O que significa maior liberdade de desenvolvimento;
• A arquitetura é plugável, permitindo maior flexibilidade no gerenciamento de serviços internos e externos.

Uma arquitetura baseada em microsserviços fatalmente te levará a construir APIs. Embora haja outras formas de fazer com que os serviços dentro da mesma se comuniquem, APIs REST são a forma mais comum para esse tipo de comunicação.

Não importando se as APIs serão públicas ou privadas (como no exemplo do Netflix), a sua necessidade é clara. Mais que isso, elas são partes fundamentais da arquitetura em si, e proporcionam o tipo de interface e abstração que faz com que a arquitetura de microsserviços fique cada dia mais popular, principalmente em empresas com uma grande quantidade de desenvolvedores e projetos.

Em contrapartida...

Você não é o Netflix. Ou o Google. Ou o Uber. Nas palavras de David Heinemeier Hansson, microservices é:

(...) a great pattern. No, really. Not being sarcastic here. If you’re Amazon or Google or any other software organization with thousands of developers, it’s a wonderful way to parallelize opportunities for improvement. Each service can be its own team with its own timeline, staff, and objectives. It can evolve independently, at least somewhat, of whatever else the rest of the constellation is doing.

Todos os prós de utilizar microsserviços vêm com um preço, e reverter essa decisão não costuma ser uma das experiências mais prazerosas, como descreve Thomas Betts, no To Microservices and Back Again - Why Segment Went Back to a Monolith.

Tive a oportunidade de trabalhar por dois anos em uma empresa que utiliza esse tipo de arquitetura, e confesso que o isolamento do teu domínio, juntamente com a flexibilidade e controle sobre o que você está executando e entregando, é incrível. Mas sem um time de DevOps para dar o devido suporte, não consigo nem imaginar o quão traumática essa experiência poderia ser.

Todo o buzz em volta de SOA e microservices fez com que automaticamente aplicações monolíticas passassem a ser "o que há de pior na sua stack". Se ontem lemos um artigo sobre todo o lore dos microsserviços, amanhã estamos com um serrote desmembrando um monolito, e no fim do dia a motivação era porque não aguentamos mais lidar com conflitos no Git.

Se APIs for pura e simplesmente um efeito colateral da decisão de "provar" o mundo dos microsserviços, eu volto a citar o DHH:

Run a small team, not a tech behemoth? Embrace the monolith and make it majestic. You Deserve It!

Agora, se microservices é a resposta para os seus problemas, API FTW!

Considerações finais

A motivação para esse artigo veio depois de uma palestra que dei sobre API-First, no DjangoDay 2020. Nos corredores, conversei com alguns participantes do evento e sob a ótica deles eu pude ter um vislumbre do quão "desconfortável" pode ser a adoção de um processo mais rígido visando a sua prática.

Em um dos diálogos, a analogia com TDD e test-first apareceu. E se por um lado ela pode ser encarada como algo positivo, por se referir a uma excelente ferramenta de design e engenharia de software; Por outro me fez refletir sobre todo o esforço e frustração que tenho até hoje em praticar test-first (o que não me impede de ter cobertura de testes, e utilizar testes como ferramenta de design de código).

No final, é tudo uma questão de contexto (e do famigerado "depende"). APIs nem sempre fazem parte da necessidade de projeto em seu início, mas passam a ser depois de alguns sprints e descobertas que o time vai fazendo. Portanto, dependendo do ponto específico no tempo em que seu projeto esteja, você não precisa de uma API.

E está tudo bem! Lembre-se que YAGNI é um bom padrão para se ter embaixo do braço.

Referências

• Better Programming - Don't follow Javascript trends
• Changelog - Monoliths are the future
• David Humphrey - How to become a Fool Stack Programmer
• FreeCodeCamp - The SaaS Handbook: How to Build Your First Software-as-a-Service Product Step-By-Step
• Hackernoon - How Microservices Saved the Internet
• InfoQ - To Microservices and Back Again - Why Segment Went Back to a Monolith
• Lifewire - What is a Web Mashup?
• MuleSoft - What is the API Economy
• Red Hat - O que são os microsserviços?
• Signal V. Noise - Stimulus 1.0: A modest JavaScript framework for the HTML you already have
• Signal V. Noise - The Majestic Monolith
• Sitepoint - Do you need an API?
• Tom MacWright - Second-guessing the modern web