Desenvolvendo uma mentalidade de plataforma para APIs

As plataformas permitem que as equipes de DevOps aproveitem a infraestrutura e seus recursos e definam um conjunto de práticas recomendadas para segurança e confiabilidade. Vamos explorar como os líderes técnicos e arquitetos podem adotar uma mentalidade de plataforma semelhante para APIs e como pode ser uma versão inicial de uma plataforma de API.

Explorando os requisitos de uma plataforma API

Uma plataforma DevOps bem-sucedida permanece coerente e eficiente em suas propostas de valor, ao mesmo tempo que satisfaz a necessidade de reunir recursos para que outros possam desenvolver. Aplicar essa mentalidade a um cenário de API proporciona consistência tanto para a tecnologia quanto para os fluxos de trabalho, o que simplifica radicalmente a experiência do desenvolvedor para os consumidores de API. Aqui estão os requisitos que ajudam a garantir uma plataforma API bem-sucedida.

Metas e responsabilidades

Se você pedir a cinco equipes que projetem uma API para um determinado problema, é praticamente garantido que o resultado serão cinco APIs diferentes. Mas uma API funciona como um contrato (formal ou não) entre quem a produz e quem a consome. Ser capaz de definir claramente como resolver um problema funcional é importante para todos os envolvidos. Portanto, você deve declarar os contratos técnicos para que os objetivos e responsabilidades fiquem claros. Aqui está um exemplo: “A plataforma suporta GraphQL, sua segurança será gerenciada via JSON Web Token (JWT) e a observabilidade será gerenciada através de OpenTelemetry.”

Estrada pavimentada

A abordagem da “estrada pavimentada” define claramente o contrato e determina o padrão para seus critérios. Ele estabelece maneiras repetíveis, reutilizáveis, automatizadas e fáceis para equipes novas e antigas aprenderem o que precisam. Por exemplo, se a maioria das equipes está desenvolvendo com Java e Spring Boot, a abordagem de estrada pavimentada significa configurar antecipadamente alguns chassis de aplicativos, bibliotecas, exemplos de código e muito mais.

Coesão

Quando um campo ou objeto utilizado em um esquema de API está alinhado com sua terminologia de negócios, essa coesão permite o uso de ferramentas como linters automatizados para detectar problemas o mais cedo possível. As equipes de API muitas vezes não percebem esse tipo de problema porque seus casos de uso parecem singulares o suficiente para que qualquer divergência seja justificada.

Self-service

O autoatendimento é a resposta para o escalonamento e ajuda a prevenir lentidão na integração. Documentação, processos e ferramentas técnicas simplificam a integração. Se for necessário realizar uma reunião, concentre-se no que agrega mais valor à empresa e ao projeto para que suas equipes possam operar com eficiência e propósito.

Hora de valorizar

Uma plataforma substitui discussões demoradas, pesquisas, definição de pipeline e disputas de segurança por documentação de integração. Ele também fornece uma maneira fácil de inicializar um novo aplicativo com todos os cortes padrão, reduzindo o tempo de valorização (TTV) para horas, se não minutos. A coleta de uso e as verificações automatizadas pela plataforma podem ajudar as equipes a saber quem está usando sua parte da plataforma e a agir de forma adequada.

Coerência

A coerência é uma verificação constante. As equipes recuam e analisam a solução para ver se há alguma lacuna ou problema que possa ser resolvido. Os recursos e capacidades crescem à medida que a plataforma evolui ao longo do tempo, mas é importante que eles se alinhem com as metas e responsabilidades declaradas — e com o contrato da plataforma.

Opinativo

Se uma API tentar fazer muito — por exemplo, expor recursos de negócios e adaptar suas respostas para aplicativos de UI — é possível que a experiência geral não seja coesa nem coerente. Você terá que fazer algumas escolhas, mas se o contexto mudar, a plataforma deverá reagir e fazer os ajustes apropriados.

Uma plataforma monolítica com múltiplas camadas de API

No mundo da plataforma de API, há uma distinção importante a fazer: ter uma plataforma única não significa que você tenha um único tipo monolítico de API. Há diferenças importantes a serem consideradas entre os processos, ferramentas e práticas em vigor e suas implementações e usos (por exemplo, o tipo de APIs que você precisará implementar).

Por que camadas?

Uma API deve servir a um propósito específico; caso contrário, a experiência do consumidor será degradada. No entanto, a tecnologia e os processos podem ser reutilizados ou adaptados. Os princípios de coerência e coesão são válidos para quaisquer APIs no mesmo nível de semântica. Um aplicativo frontend tem as mesmas necessidades de API que uma ferramenta CLI ou outro serviço no domínio? Você poderia tentar implementar uma abordagem única, mas com o tempo, as necessidades de suas equipes irão divergir e a frustração aumentará.

Para acomodar vários casos de uso, você pode usar tipos de APIs em camadas. Essas camadas podem servir a diferentes propósitos por meio de uma forma de abstração. As empresas que escolheram esse caminho estão percebendo um aumento na velocidade, bem como na capacidade de iterar sem tanta coordenação. Esta abordagem pode impulsionar a consistência tanto para produtores como para consumidores. Além disso, uma mudança para uma abordagem unificada e federada pode permitir que você dimensione APIs, reutilize a infraestrutura e envie código com mais rapidez. Vamos ver como fica esses tipos de APIs:

• API de domínio: Expõe as principais funcionalidades do negócio
• API de experiência do cliente (CX): oferece suporte ao desenvolvimento de front-end, responde a perguntas CX e usa a API de domínio para todas as questões de negócios

Regras de engajamento de API: uma história de CX e domínios

Aqui está um exemplo de como uma plataforma de API poderia ser com uma arquitetura que combina várias APIs GraphQL em um gráfico de gráficos que as equipes do cliente podem consultar a partir de um único endpoint.

Neste diagrama, o conceito de plataforma API é aplicado duas vezes, na experiência do cliente e nos contextos de API de domínio. É possível ter regras de linting, processos de revisão de esquema, autorização e autenticação que variam de acordo com os requisitos. No entanto, como os padrões de engenharia de plataforma são seguidos, a automação e a repetibilidade inerentes a esta abordagem simplificam o gerenciamento dos dois escopos.

Com a configuração correta, você pode “vincular” entidades de domínio de vários domínios. Por exemplo, o conceito de User provavelmente estaria presente no User domínio e também no Order domínio. Embora ambos falem do mesmo “Usuário”, as perspectivas desses domínios podem ser diferentes – um com todas as informações do perfil (por exemplo, nomes, endereços, preferências de marketing, fidelidade) e outro com dados necessários para atender um pedido ( por exemplo, nomes, endereço de cobrança, endereço de entrega).

Definição de políticas de segurança

No que diz respeito à segurança, a plataforma API unifica a forma como os consumidores podem aproveitar os recursos com aspectos de autenticação e autorização. No contexto de uma API de domínio apoiada por um gráfico de gráficos, cada domínio pode expressar uniformemente quem pode acessar qual recurso, com um gateway GraphQL executando a aplicação em tempo de execução.

Conclusão

Os requisitos da sua plataforma evoluirão junto com os requisitos dos seus aplicativos. Uma plataforma, portanto, deve sempre evoluir com base nas necessidades dos seus utilizadores e, em muitos aspectos, é um produto em si.

A postagem Desenvolvendo uma mentalidade de plataforma para APIs apareceu pela primeira vez em The New Stack.