Design orientado a eventos: o poder das notificações de eventos

Segunda parte da série sobre “Saiba projetar APIs confiáveis e robustas”.

Com o passar do tempo, mais empresas passaram a adotar APIs event-driven – também chamadas de “real-time” – a seus programas. O Event-sourcing ( ES ) e o Command-Query Responsibility Segregation ( CQRS ) são os padrões de arquitetura mais discutidos no momento.

No entanto, existem estilos de arquiteturas menos intensivos e igualmente valiosos, como a implementações de notificação de evento ( EN ) e Event-carried State Transfer ( ECS ). Os padrões de notificação e event-carried são relativamente fáceis de introduzir em um sistema RESTful existente e oferecem algumas opções para implementação e consumo.

Nesta parte de “Saiba projetar APIs confiáveis e robustas”, será explorado o mais simples desses quatro padrões arquiteturais: a notificação de evento (EN). Desta forma, será possível demonstrar como ela é frequentemente usada para aprimorar implementações RESTful.

Anatomia de uma notificação de evento

As ENs são cadeias simples que anunciam ações ou eventos dentro do domínio. Por exemplo, “Seu pacote foi entregue” ou “Servidor q1w2e3 está ficando sem memória”. Essas mensagens podem aparecer no telefone celular ou como um “pop-up do sistema” na interface da área de trabalho, ou seja, eles são essencialmente alertas.

Pelo menos na maioria das notificações em seu telefone ou desktop, ENs que são usadas ​​em interações API de máquina para máquina, sendo que geralmente carregam uma mensagem simples. Esse é um elemento-chave das ENs: elas possuem um público-alvo.

Outro aspecto importante das ENs, é que elas não carregam informações muito detalhadas. Assim sendo, é possível, por exemplo, receber um aviso no telefone informando que um de seus servidores está funcionando mal. Contudo tal aviso não terá detalhes sobre qual é o problema ou quando ele começou.

Com isso, as ENs costumam conter links que apontam para uma fonte de informação mais detalhada e definitiva. Desta forma, junto com uma cadeia descritiva, essas notificações também possuem um link para outro recurso. 

Além disso, esses padrões arquiteturais podem conter um carimbo de data e hora para adicionar algum contexto à mensagem. Isso ajuda se, por exemplo, alguém estiver coletando e armazenando as mensagens para revisão posterior. Portanto, se as ENs são apenas cadeias simples de informação, o que as torna úteis em um sistema de TI corporativo? 

Alertas e notificações

Embora as ENs sejam muito simples, elas podem ter um grande impacto na arquitetura do software – tanto para aplicativos voltados para o cliente, quanto para o servidor. Um ótimo exemplo de notificações, até mesmo pelo viés do usuário, é o pop-up na área de trabalho e em dispositivos móveis. Estas, são mensagens curtas que lembram a pessoa de pegar um pão no mercado, verificar o status do feed de sua rede social ou se preparar para aquela reunião que está prestes a começar em cinco minutos.

Do lado do cliente, as ENs são frequentemente usados ​​como “notificações” para encorajar a interação e o envolvimento do usuário. Adicioná-los aos seus próprios aplicativos do lado do cliente pode melhorar a experiência do usuário sem sobrecarregar o sistema.

Um exemplo muito comum de ENs do lado do servidor é o uso de mensagens de rastreamento e registro para seus serviços. A maioria das plataformas possui alguma forma de coletar ações-chaves em serviços, como logins de usuários, check-outs de carrinho de compras e formulários preenchidos. Frequentemente, essas informações são indicadoras de sucesso (checkout em compras) ou de fracasso (compras abandonadas) no nível de negócios.

Assim sendo, ENs são essencialmente alertas e normalmente exibidos em painéis ao vivo em vários locais da empresa para rastrear a saúde e o bem-estar da TI da empresa.

Alertas do lado do servidor e notificações do lado do cliente, são uma ótima maneira de melhorar o envolvimento e a capacidade de observação de seu sistema sem ter que fazer muita reengenharia.

Frequentemente, as notificações do lado do servidor podem ser tratadas como um complemento para os sistemas existentes, sem reescrever o código. As ENs do lado do cliente geralmente requerem codificação adicional para que os aplicativos possam ouvir e responder às mensagens quando elas aparecem.

Resumindo

Conforme se trabalha para adicionar mais suporte para interações EVENTful à sua plataforma, as notificações de eventos são uma ótima maneira de começar. Eles geralmente exigem um investimento limitado e podem fornecer um feedback valioso.

Tendo em vista que EN geralmente são apenas alertas e sugestões, é possível apresentá-los a um ecossistema sem exigir alterações em seus modelos de dados, interfaces de objetos ou processos de fluxo de trabalho. 

O próximo passo na jornada de RESTful para EVENTful significa subir de nível no conteúdo de suas mensagens. No próximo capítulo desta série, iremos tratar sobre event-carried state messages (ECS).

Para ver como o MuleSoft oferece suporte a padrões event-driven usando um mecanismo reativo, verifique o mecanismo de tempo de execução Mule e para mais informações sobre o design de APIS, confira meu novo livro “Design and Build Great Web APIs: Robust, Reliable, and Resilient”.

Se você gostou da série até aqui, em breve lançaremos o último artigo da série!

Este artigo foi escrito por Mike Amundsen e publicado originalmente em Prensa.li.