Webinar | Estratégias APIs sem impacto em Backends Legados

Estratégias de Exposição de APIs em Legados

Fabrício Rosato (Sensedia)

A apresentação de hoje, com Fabrício Rosato, focará em "Exposição de APIs em Backends Legados e Travados". Fabrício é profissional da Sensedia e professor em cursos de pós-graduação, deixando seus contatos à disposição para dúvidas ou sugestões.

A Sensedia é uma empresa especialista em arquitetura e integrações, muito voltada para APIs, sendo reconhecida como Visionária no Quadrante Mágico do Gartner. Em outro estudo da Forrester, a empresa foi colocada como "Strong Performer", gabaritando a Sensedia como forte no segmento.

A Sensedia realiza o evento anual APIX, que teve sua 4ª edição marcada para agosto de 2018. O evento anterior, em 2017, reuniu 700 pessoas com conteúdo estratégico e técnico, e o convite está feito para que todos aproveitem.

‍

Conteúdos ricos como webinars, gravados ao longo do tempo, estão disponíveis no site da Sensedia para acesso a qualquer momento. A empresa se posiciona acreditando que "todos os negócios são digitais" e que as APIs criam e habilitam essas experiências digitais.

As APIs tornam plataformas e empresas mais abertas e conectadas, sendo um tema central para a Sensedia e para o conteúdo deste webinar. A agenda inclui discutir APIs Legadas, estratégias de exposição, vantagens/desvantagens e tecnologias.

Também serão abordados os caminhos das pedras para se ter um avanço e uma abordagem de sucesso neste tema específico. A definição técnica de API é que ela visa ser simples, segura, com baixo acoplamento e de forma padronizada/interoperável.

‍

O objetivo é que um developer consiga construir uma aplicação que se comunique com o backend no menor tempo possível (time-to-market). É buscada a simplicidade do design, evitando endpoints com nomenclatura malformada ou construídos "de qualquer jeito".

Um estudo da Sensedia divulgado no APIX mostrou que 80% das grandes e médias empresas aumentaram a quantidade de APIs em produção entre 2016 e 2017. Isso demonstra um forte investimento e crescimento neste tipo de estratégia mais estruturada.

Os principais drivers (casos de uso) para esse investimento são: ecossistema de parceiros digitais (como marketplaces de e-commerce), experiências digitais (para mobile e outros canais), e inovação aberta/criação de plataformas (como o caso da Cielo LIO).

‍

As APIs atuam como fronteira entre essas experiências/ecossistemas/plataformas e o backend, onde está o grosso da regra de negócio. A plataforma de APIs da Sensedia garante design, segurança, conectividade, governança e escalabilidade para todas as APIs em execução.

O termo "legado" traz consigo estigmas como aplicação monolítica, problemática, difícil de evoluir, ou tecnologia obsoleta/não suportada. No entanto, isso não é uma verdade absoluta, pois uma aplicação recém-construída já pode ser considerada um legado.

O foco é nas aplicações legadas mais difíceis, com travas tecnológicas e maior dificuldade de evolução, usando APIs para "destravar" esses sistemas. Um legado pode ser um sistema super importante para o negócio, com impacto positivo.

Existem inúmeras razões para manter um legado: ele funciona satisfatoriamente, não há justificativa técnica/financeira para a mudança, ou o custo de mudança é muito baixo. Em arquiteturas reais, os sistemas legados transcendem a aplicação monolítica.

‍

Na "System Layer" (camada de sistemas) podem existir mainframes, FTP, bancos de dados, e até aplicações SaaS, lado a lado. Esses sistemas podem prover uma "Service Layer" (camada de serviço) via diversos protocolos (SOAP, REST, etc.) que nem sempre são agnósticos à tecnologia.

Ao definir a estratégia de exposição, é crucial evitar o anti-pattern "Ball of Mud", onde se usa uma ferramenta para gerar uma API automaticamente a partir de um objeto de código ou banco de dados legado. Isso carrega vícios do legado para o design da API.

A abordagem ideal é o "API-First" ou "Outside-In": começar a pensar na API a partir da necessidade e processos de negócio, histórias e jornadas digitais. A partir daí, verifica-se como os sistemas/serviços internos e legados podem suportar essa estratégia.

‍

O objetivo é pensar primeiro nos endpoints e, se os sistemas e protocolos legados não proverem um formato ideal (como JSON), será necessária uma camada de transformação. Essa camada verde é chamada de "API Front" (um padrão da Sensedia).

O API Front visa transformar as diferenças do backend (tratando protocolos e payloads) e expor o serviço no formato ideal, agindo como um colchão de absorção para abstrair toda a complexidade do backend.

‍

Estratégias de Exposição (Sem Impacto no Código Legado)

O primeiro tipo de estratégia é lançar mão do API Front para conectar-se ao legado, fazendo transformação de protocolo (payload) e expondo em formato REST. No entanto, nem sempre será possível ter uma API puramente RESTful, seguindo todos os princípios.

O legado pode ter limitações (ex: não suporta paginação), e a dica é "ser o mais prático possível" na abordagem, aceitando a limitação para avançar rápido e ter a API. Algumas arquiteturas mostram o tradicional client-server com uma API "isolada" ou não legal.

Se o server (aplicação) tem essa API não legal (RPC, CORBA, etc.), essa é uma oportunidade para o API Front transformá-la em uma API organizada, de preferência REST. Outra situação é ter uma API de backend com design ruim (RPC que faz um request e retorna um conjunto de informações).

‍

Nesse caso, o API Front cria uma camada intermediária que tem um design de API "bacana" (seguindo princípios de nomenclatura, recursos e métodos). Essa camada converte a chamada para a API ruim do backend, expondo-a de maneira adequada.

Uma outra abordagem muito utilizada, especialmente em projetos da Sensedia, é transformar informações de mainframes em APIs. Mainframes podem se comunicar via serviços que retornam strings funcionais, Web Services ou XML não padronizados.

Se houver a possibilidade de se comunicar com o mainframe por algum protocolo de acesso à informação, o API Front pode fazer a requisição (ex: via string funcional) e transformar a resposta em JSON, utilizando o máximo de princípios REST possíveis.

Isso é legal pois traz agilidade para quem consome a API, que muitas vezes nem saberá que há um mainframe por trás. O legado é fortemente modernizado, apesar de ter que lidar com protocolos não triviais.

‍

Vantagens da Estratégia (Sem Impacto): Aproveitar ao máximo as funções de negócio (passando por uma camada de serviço), e não precisar fazer alteração no código da aplicação legada. A transformação é apenas de protocolo e formato de dados.

‍

Riscos da Estratégia (Sem Impacto): Grande diversidade de protocolos para acessar o legado (exigindo adaptadores no API Front), dificuldade de entender quais endpoints e serviços estão disponíveis no legado (falta de mapeamento).

Outros riscos incluem dificuldade de aderência aos padrões REST devido a limitações do backend e dilemas em cenários de composição (consumir mais de um serviço para compor uma API). O principal é o risco de escalabilidade.

O backend legado pode não estar preparado para lidar com o aumento de carga que a exposição da API (ex: para uma aplicação mobile) vai gerar, podendo receber duas vezes mais requisições do que suporta.

‍

Outra estratégia, que diminui a aderência ao API-First, é acessar direto a base do sistema legado via API Front, se não houver uma camada de serviço. A vantagem é não ter alteração de código, indo direto ao ponto.

O risco é que, se a informação tiver regras de negócio embarcadas na aplicação, o acesso direto à base perde essas regras. A menos que haja uma view que contenha a regra, o API Front pode ter que implementar regras de negócio.

Isso faz com que o API Front se torne complexo e com baixa coesão, emulando a aplicação de regra de negócio, o que é uma abordagem pró-ativa, mas precisa ser balanceada. O último caso é fazer HTML Scraping em um formulário ou informe do HTML.

‍

A vantagem é aproveitar as funções de negócio da interface e não precisar alterar a aplicação, sendo interessante para cenários de MVP ou testes rápidos. Porém, é fortemente não recomendável para produção.

Os riscos são grandes: dificuldade de parsing do HTML, qualquer alteração no front-end impacta a API, questões legais (consumir um portal que não é seu) e problemas de escalabilidade. Em casos extremos, onde o backend não tem abertura (nem banco de dados), pode ser a única opção.

Tecnologias como Node.js (com o cheerio) podem ser usadas para fazer o parsing e scraping de HTML (usando POST ou GET).

‍

Estratégias de Exposição (Com Impacto no Código Legado)

A ideia é criar uma API padronizada mexendo no legado: a primeira estratégia é criar uma camada de APIs de forma padronizada (preferencialmente REST/HTTP/JSON) dentro da própria aplicação legada. Isso é totalmente factível se o acesso ao legado permitir.

Outra oportunidade é, se a tecnologia do legado não suportar REST, criar uma camada de APIs não-REST (joana) com protocolos que o legado comporta. Depois, utiliza-se um API Front para transformar isso no padrão REST.

Essa última estratégia envolve dois trabalhos: criar a camada no legado e depois transformá-la em REST padronizado no API Front.

‍

Tecnologias para API Front

O API Front pode ser construído com tecnologias commodity como Node.js, .NET, Python ou Java, que dão conta de conectar-se ao legado e fazer o código de transformação. Frameworks (ex: Spring, Apache Camel) podem facilitar, dependendo do skill da equipe.

É importante ter um padrão de arquitetura para o API Front, usando interceptadores para sessões genéricas e classes utilitárias para conexão e processamento de stream. A dica de arquitetura é quebrar o API Front em pequenos pedaços (microservices).

‍

Essa decomposição funcional permite autonomia e facilidades na evolução e deploy. Além das tecnologias commodity, pode-se usar tecnologias mais específicas, como ESBs (Enterprise Service Bus) ou Leaders de integração.

ESBs (como Oracle e IBM) são bons em conectividade e transformação, mas estão sendo menos utilizados por serem pesados. Frameworks leves (Spring, Apache Camel) são boas alternativas para conectividade e transformação para um formato de API padronizado.

‍

Requisitos Não-Funcionais e API Gateway

No API Front, é necessário lidar com questões não-funcionais (NFRs) como segurança (tokens), tratamento de dados (JSON/XML/string), logging/analytics, caching, monitoria/alertas e rate limiting. Isso pode ser feito via código ou com tecnologias prontas.

Uma abordagem é incluir um API Gateway na frente do API Front para interceptar e cuidar dessas NFRs. O Gateway delega mecanismos não-funcionais, lidando com segurança, tokens, analytics e onboarding de developers (via Swagger/SDKs).

Isso é interessante porque o API Front foca apenas em conectividade e transformação, não se tornando uma camada "super absorvente" de NFRs.

‍

Caminho das Pedras (Roadmap)

O processo envolve etapas de Planejamento, Design e Execução. O principal é se organizar, especialmente em empresas grandes, e lidar com a barreira cultural ("Por que expor API se já tenho SOAP/RPC?").

Se a empresa tiver um direcionamento digital, a justificativa fica mais fácil. Pensando no design ideal (API-First), deve-se pensar no negócio, usabilidade, e criar uma camada de abstração para mitigar riscos do legado.

‍

A dica é começar pelo design (API Design): pensar no negócio, e, se houver um time de front-end e outro de backend (legado), o design pode liberar a equipe de front-end para construir o consumo da API.

Pode-se usar uma estratégia de mocking para testar o front-end enquanto a equipe de backend identifica os serviços para plugar o API Front. Em seguida, implementa-se o API Front, pluga-o ao backend e publica a API (preferencialmente REST).

O ciclo pode se repetir com base no feedback dos developers consumidores, buscando o design mais completo possível.

‍

Tecnologias por Fase: Open API Specification/Swagger para Design, plataforma de API Management para Mock e Try Out, tecnologias commodity (ex: Spring) para Implementação (API Front), e API Gateway para Publicação (mecanismos não-funcionais).

‍

Papéis Envolvidos

Os papéis a serem estabelecidos no projeto incluem: API Product Owner (define APIs e modelo de negócio), API Architect (desenha APIs, pensa na experiência do developer), Developer (constrói o API Front e conecta ao backend).

Há também o Analista de Negócio (apoia o entendimento), Arquiteto de Backend (identifica serviços legados), API Operator (publica, monitora, garante o funcionamento) e o DevSec (segurança).

A Equipe Cliente/Parceiros é quem consome a API. Nem todos os papéis são estritamente necessários, mas cobrem a maioria dos cenários.

‍

Dicas Finais

Aproveite ao máximo o poder do legado para expor suas APIs, pois ele tem um valor gigante. Faça escolhas estratégicas e utilize a tecnologia adequada para a estratégia definida.

Monte um time multidisciplinar e pense sempre em "API-First" para ter sucesso na abordagem.