.png){kind=small}
.png){kind=small}
Publicado originalmente em NordicAPIs
Os desafios impostos por qualquer negócio digital geralmente se concentram na agilidade e escalabilidade. Ainda assim, hoje em dia, as arquiteturas de software tradicionais não suportam o volume de dados e padrões de integração necessários para permitir um negócio competitivo. Implementar soluções alternativas para disponibilizar ativos digitais de forma segura e escalonável é a chave para o sucesso da jornada digital de uma empresa.
Existem várias maneiras de definir o que é uma API. Resumindo, APIs são interfaces técnicas que permitem a construção de ecossistemas integrados. Ao desenvolver produtos digitais e alavancar sua conectividade por meio de APIs, é possível se conectar a uma variedade de parceiros, entregar serviços para desenvolvedores de aplicativos e permitir a reutilização de serviços internos, entre outros benefícios .REST é o estilo mais comum utilizado por expositores de API. No entanto, surgiram novas alternativas como GraphQL ou gRPC . Dependendo do caso de uso (integração interna entre microsserviços ou flexibilidade para os desenvolvedores escolherem quais dados desejam na resposta), esses novos estilos podem trazer mais benefícios para uma estratégia de integração.
Um evento é qualquer ação que provoca uma mudança sistêmica de estado. Em outras palavras, um evento é uma atualização em um aplicativo que gera valor para alguém (por meio de outro aplicativo).Para contextualizar, considere os eventos em um sistema de pagamento com cartão de crédito. Cada vez que um usuário tenta um pagamento com seu cartão de crédito, uma notificação é gerada para informar ou solicitar a confirmação. Observe que nem toda ação ou atualização executada em um aplicativo é considerada um evento. Em vez disso, os eventos devem sempre estar vinculados a um valor comercial significativo.Em uma integração baseada em eventos (também conhecida como Event-Driven Architecture (EDA), os consumidores se inscrevem em eventos e recebem notificações deles. Isso se opõe ao modelo de integração definido por APIs tradicionais, onde os consumidores fazem solicitações de pool para obter as informações que eles necessidade. Três elementos principais compõem um EDA:
Existem duas topologias principais para implementar uma arquitetura orientada a eventos, usando um mediador ou corretor:
Um mediador é considerado em cenários onde há requisitos para manipular ou orquestrar o evento.
Os produtores de eventos publicam eventos em uma fila para serem consumidos pelo Mediador. Isso pode ser notificado sobre o novo evento ou ler a fila de forma proativa. Em seguida, o Mediador fará a orquestração do evento, enviando-o na ordem certa para os diferentes Processadores, e ainda enriquecendo o evento com conteúdo proveniente de serviços anteriores, se necessário. Por exemplo, em um processo de geração de pedido, um serviço responsável pela gestão de estoque tem interesse em receber notificações quando produtos forem adicionados a um carrinho de compras, para informar sua disponibilidade. E o serviço de faturamento precisará saber se há produtos disponíveis para gerar a fatura do pedido.
Nas situações em que não há requisitos de orquestração, a recomendação é a adoção de Broker.
Semelhante à Mediação, o evento será compartilhado com a Corretora (via enquete ou push, dependendo da decisão de arquitetura tomada). A principal diferença é que o evento será enviado a todos os Event Processors interessados neste evento. Seguindo nosso exemplo anterior, o carrinho de compras, após a geração de um novo pedido, o serviço de gerenciamento de pedidos enviaria uma notificação de evento para a fila de serviço de gerenciamento de estoque. Se houver produtos disponíveis, esse serviço pode enviar uma nova notificação de evento para a fila de serviço de faturamento para gerar uma fatura.Decidir entre mediador ou corretor é uma decisão arquitetônica que dependerá dos requisitos e problemas de negócios que você está tentando resolver.
Embora ambos os modelos pareçam se opor, eles são, na verdade, complementares um ao outro. Em um cenário híbrido, as APIs aproveitam as interações online onde os aplicativos exigem feedback instantâneo para as ações realizadas, enquanto os eventos aproveitam as comunicações assíncronas. Ambas as tecnologias combinadas podem ser muito poderosas. Essa combinação pode permitir que as empresas permitem que clientes ou parceiros obtenham o melhor da palavra síncrona de duas maneiras: primeiro, ao fazer chamadas de API para criar pedidos ou iniciar pagamentos e, segundo, ao recuperar atualizações de rastreamento após receber uma notificação de evento.Existem implementações de arquiteturas orientadas a eventos que fornecem não apenas a notificação em si, mas também o conteúdo atualizado. Mas mesmo nessa abordagem, uma API poderia ser acionada internamente para recuperar as atualizações a serem entregues aos assinantes do Evento.
Não é difícil pensar em cenários combinando APIs e eventos. Podemos olhar para o mundo do Open Banking , um campo em expansão para APIs, para obter alguns insights excelentes.Os bancos desempenham um papel crucial no Open Banking, uma vez que detêm a maioria dos dados dos clientes. Os terceiros provedores (TPPs), por outro lado, estão interessados nos dados do cliente para potencializar vários casos de uso. Essas áreas incluem a opção de hipoteca mais acessível, o melhor provedor de seguros ou mesmo agregação de contas, que coloca todos os detalhes de poupança e conta corrente de diferentes bancos em uma única exibição.A maneira como os TPPs recuperam dados do banco é por meio de chamadas de API . Mas, uma solução deve iniciar uma nova chamada de API toda vez que alguém abre um aplicativo para verificar a integridade de suas contas? A resposta é não!Usando eventos, os TPPs podem ser notificados apenas quando algo muda. Acionar uma API para atualizar as informações apenas quando necessário evita chamadas perdidas. Este é um exemplo simples onde APIs e eventos podem ser combinados para entregar valor real a todo o ecossistema.
Uma estratégia de integração baseada em recursos síncronos e assíncronos pode ser muito benéfica para consumidores e provedores de API. Os consumidores não precisam construir sua integração com base em solicitações de pooling constantes enviadas aos provedores. Eles podem oferecer um modelo de integração que reduz a carga em seus servidores e direciona importantes momentos de negócios.Antes de decidir o modelo de integração, é muito importante identificar seus clientes e parceiros-alvo, bem como a melhor forma de integração com eles para fornecer seus serviços. Somente após a conclusão desta análise, o modelo de integração mais adequado pode ser definido.
