Quando usar webhooks, WebSocket, pub/sub e polling

Uma das formas mais simples de aplicações online compartilharem dados é por meio de webhooks, um formato de comunicação unidirecional para mover dados de uma aplicação para outra. No entanto, webhooks não são o único método de transferência de dados entre aplicações em rede. Como pessoa desenvolvedora, é muito importante usar a ferramenta certa para o problema certo, ou você corre o risco de trivializar ou superdimensionar a solução.

Neste artigo, vamos começar vendo como os webhooks funcionam. Depois, vou comparar esse processo com outras técnicas de compartilhamento de dados usadas por arquiteturas modernas, para associar cada técnica aos cenários em que ela deve ser usada.

Depois das comparações vem a resposta para a pergunta que talvez mais te ocupe: quando eu devo usar webhooks?

Webhooks vs. polling vs. WebSockets vs. pub/sub vs. APIs

Antes das comparações detalhadas, veja como os cinco padrões de comunicação abordados neste artigo diferem nas dimensões que normalmente decidem qual deles você vai escolher:

As seções abaixo explicam cada comparação com mais profundidade.

Como os webhooks funcionam

A comunicação por webhook acontece com o envio de uma requisição HTTP de uma aplicação de origem para uma aplicação de destino. Quando um evento acontece na aplicação de origem, uma requisição HTTP — que pode conter dados relacionados ao evento — é disparada. Essa requisição é enviada ao endpoint da aplicação de destino (muitas vezes chamado de webhook URL).

Requisições de webhook podem ser enviadas com os métodos POST ou GET. Isso depende das preferências do provedor do webhook — a informação sobre como consumir as requisições está sempre disponível na documentação do provedor.

Agora que temos um bom entendimento de como os webhooks funcionam, vamos às comparações.

Webhooks ou WebSockets

Como os WebSockets funcionam

WebSockets são usados para facilitar a comunicação bidirecional em tempo real entre dois sistemas em rede. Eles fazem isso mantendo um socket aberto tanto no cliente quanto no servidor durante toda a conversa.

Isso abre um fluxo de comunicação duplex, permitindo que cliente e servidor troquem informações entre si sem latência significativa.

Diferenças entre webhooks e WebSockets

Webhooks são usados para comunicação unidirecional de uma aplicação de origem para uma aplicação de destino, enquanto WebSockets facilitam a comunicação bidirecional entre servidor e cliente.

Webhooks são usados majoritariamente por dois servidores para trocar informação, enquanto WebSockets são usados principalmente para comunicação servidor-cliente (na maioria das vezes, navegadores).

Além disso, webhooks fecham a conexão de socket na aplicação receptora assim que uma resposta é devolvida, enquanto WebSockets mantêm a conexão aberta pelo tempo que for necessário, e não apenas para uma única transferência de informação.

Em termos de protocolo de comunicação, o WebSocket usa o seu próprio protocolo WS, enquanto webhooks usam HTTP comum.

Quando usar WebSockets

Use WebSockets quando quiser comunicação bidirecional entre dois sistemas em rede, por exemplo ao construir uma aplicação de chat. WebSockets também são muito úteis para dashboards de visualização de dados ou mapas que precisam refletir valores em tempo real.

Webhooks ou pub/sub

Como o pub/sub funciona

Pub/sub, abreviação de publish/subscribe, é um sistema de comunicação para distribuir mensagens entre um conjunto de publishers (produtores de mensagem) e subscribers (consumidores de mensagem). Um sistema de pub/sub armazena em buffer as mensagens dos produtores e as roteia para os assinantes por meio de canais dedicados conhecidos como topics. Publishers publicam mensagens em topics e subscribers manifestam interesse assinando esses topics.

Assim que uma mensagem é publicada em um topic específico, ela é clonada e enviada a todos os assinantes daquele topic.

Diferenças entre webhooks e pub/sub

Em um sistema de pub/sub, as origens das mensagens são desacopladas dos consumidores, enquanto em webhooks o produtor da mensagem sabe exatamente onde o consumidor está, por meio da webhook URL.

Webhooks são uma forma direta de comunicação entre produtor e consumidor, enquanto o pub/sub é um framework intermediário que roteia mensagens dos publishers para os subscribers. A configuração de comunicação de um webhook é um para um, ou seja, um produtor para um consumidor, enquanto em um sistema de pub/sub você pode ter muitos produtores enviando mensagens para múltiplos consumidores.

Quando usar pub/sub

Use um sistema de pub/sub quando tiver múltiplos consumidores interessados na mesma mensagem ou mais de um produtor de mensagens.

Use também um sistema de pub/sub quando quiser processar mensagens de forma assíncrona. Webhooks são síncronos.

Um exemplo de situação em que o pub/sub é apropriado é um site de e-commerce. Quando um cliente faz uma compra, você precisa enviar a nota fiscal por e-mail, mandar informações para o setor de entregas e registrar a venda no seu CRM. Vamos imaginar que um serviço de e-mail, um serviço de entrega e um serviço de registros cuidem dessas responsabilidades, respectivamente.

São três sistemas interessados na mesma mensagem. Você pode publicar essa mensagem em um sistema de pub/sub, que então a roteia para esses três serviços assinantes.

Webhooks ou polling

Como o polling funciona

Polling significa fazer requisições periódicas a um sistema para verificar se há novos eventos ou dados. Se houver dados novos, uma resposta é devolvida com esses dados no payload. Se não houver, nada é retornado.

O polling é usado para consultar sistemas em busca de novas informações e pode ser configurado como um cron job automatizado que roda em determinados intervalos.

Para captar a diferença entre as duas abordagens com um exemplo do cotidiano: polling é como ir até o correio para ver se chegou correspondência. Usar webhooks é basicamente receber a correspondência em casa toda vez que ela chega, simplesmente por ter dado o seu endereço ao carteiro.

Como os webhooks diferem do polling

O polling usa o modelo pull de comunicação, em que um sistema puxa informação de outro, enquanto webhooks usam o modelo push, empurrando informação de uma aplicação de origem para uma de destino.

Requisições de polling são feitas por um cliente, enquanto requisições de webhook são feitas por um servidor. Webhooks também são disparados automaticamente quando um evento ocorre, ao passo que o polling é configurado para rodar em intervalos fixos e roda haja ou não um novo evento.

O polling pode consumir muitos recursos, e você precisa julgar se o esforço vai ser produtivo ou não. Não é o caso das requisições de webhook, que só acontecem quando há informação nova.

Quando usar polling

O polling pode ser usado quando você não precisa de atualizações em tempo real, especialmente quando os dados mudam com muita frequência e receber uma atualização a cada mudança poderia derrubar o seu sistema.

Imagine que você tem uma startup de sucesso e o número de usuários cresce em cem por segundo. Você quer um telão no meio do escritório mostrando a contagem atual de assinantes. Se inscrever para receber dados novos a cada novo cadastro seria um caos.

O que você deve fazer é consultar o seu servidor a cada cinco ou dez minutos para buscar o total atual de usuários. Isso daria menos trabalho ao seu sistema e, no fim das contas, consumiria menos recursos.

Webhooks e APIs

O que é uma API?

Uma API é a porta de entrada de uma aplicação para o mundo. É a interface que permite que outros sistemas interajam com a aplicação. A aplicação pode expor o quanto quiser e manter as demais partes abstraídas.

APIs costumam ser um conjunto de endpoints que os clientes podem chamar para se comunicar com o sistema. Essa comunicação acontece por meio de métodos de requisição como GET ou POST, e pode carregar informações relacionadas à ação que o cliente quer executar.

Como os webhooks diferem das APIs

Webhooks fazem chamadas a APIs. Uma API dá aos webhooks o ponto de entrada para empurrar dados a uma aplicação. Quando um evento acontece na aplicação de origem, uma requisição de webhook é disparada para um dos endpoints da API.

Os dois são complementares, e não concorrentes: você chama uma API quando precisa de algo, e um webhook chama você quando algo acontece.

A maioria das integrações usa os dois: APIs para enviar comandos e ler estado, webhooks para reagir a mudanças sem ficar consultando por elas.

Quando usar webhooks

Agora que você tem um bom entendimento de como funcionam webhooks e os outros sistemas de comunicação, em quais cenários faz sentido optar por webhooks?

Webhooks são um modelo simplificado de comunicação, então você deve usá-los quando precisar do seguinte:

• Comunicação unidirecional em tempo real (da origem para o destino)
• Uma conexão não persistente entre os dois sistemas
• Responder imediatamente a um evento de uma aplicação SaaS que suporta webhooks
• Usar o modelo push para enviar atualizações imediatamente
• Comunicação um para um

Muitas aplicações SaaS usam webhooks para comunicação — por exemplo, a Shopify usa webhooks para comunicar eventos como a atualização de um carrinho de compras ou a realização de uma venda. A Stripe usa webhooks para comunicar eventos como atualizações de conta, pagamentos etc.

Exemplos desse tipo de cenário incluem:

1. Uma loja de e-commerce notificando a sua aplicação de faturamento sobre uma venda
2. Lojas de e-commerce notificando lojistas quando um item específico está sem estoque
3. Um gateway de pagamento notificando lojistas sobre um pagamento
4. Sistemas de controle de versão notificando a equipe sobre um commit em um repositório
5. Sistemas de monitoramento alertando administradores sobre um erro ou atividade incomum em um sistema
6. Sincronização de informações entre sistemas — por exemplo, quando uma pessoa muda o e-mail no seu sistema de RH ou CRM, o e-mail também é alterado no sistema de folha de pagamento ou faturamento

Exemplos de sites que usam webhooks

Sites que enviam webhooks para notificações e compartilhamento de informação

1. Webhooks da Shopify sincronizam com a Shopify e executam código quando um evento acontece na sua loja.
2. Webhooks do GitHub notificam a sua aplicação quando eventos como pushes, pull requests e issues acontecem no seu repositório.
3. Webhooks da Stripe notificam a sua aplicação quando um evento acontece na sua conta.
4. Webhooks da Twilio transmitem informações sobre eventos como SMS entregues, chamadas de voz e autenticação. … e há muitos outros exemplos.

Sites que processam webhooks

1. Hookdeck: faz a ingestão, escala e monitora o tráfego de webhooks
2. Zapier: usa webhooks para conectar diferentes aplicações nos seus fluxos de trabalho
3. IFTTT: conecta diferentes aplicações e dispositivos para ampliar suas funcionalidades

Como a Hookdeck ajuda

Depois de decidir que webhooks são o padrão certo, começa o problema mais difícil: construir a infraestrutura para recebê-los de forma confiável em escala de produção. O que começa como um único handler de endpoint vira filas, workers de retry, ferramentas de observabilidade, verificação de assinatura e runbooks operacionais (antes mesmo de você entregar a funcionalidade que os webhooks deveriam sustentar).

O Event Gateway da Hookdeck é uma infraestrutura de webhooks gerenciada que cuida da ingestão, da entrega com backpressure, dos retries, da observabilidade e da verificação de assinatura de forma nativa. Ele fica entre os seus provedores de webhook e a sua aplicação, funcionando como uma fila gerenciada para absorver picos de tráfego, fazer buffer das entregas e dar a você o rastro completo de cada evento, sem que você precise operar nada disso. Comece com a Hookdeck e pule os meses de encanamento que uma infraestrutura de webhooks em produção normalmente exige.

Conclusão

Saber quais são as ferramentas certas para resolver um problema é o que diferencia bons engenheiros. O fato de uma técnica ser simples, elegante ou amplamente adotada não a torna automaticamente a melhor ferramenta para o trabalho. Webhooks são diretos e simples de implementar, mas nem sempre são o caminho certo para o problema que você está tentando resolver. Entender as vantagens e as limitações dos webhooks vai te ajudar a identificar os lugares certos para implementá-los. Depois de decidir usar webhooks, veja o nosso guia sobre boas práticas para colocar webhooks em produção.