Webhooks vs. polling

Quando construímos aplicativos Web, frequentemente temos múltiplos serviços. Na grande maioria dos casos, eles consistem em muitos serviços Web diferentes trabalhando juntos. Neste tipo de aplicativo Web, que consiste em múltiplos serviços, como transmitir dados é algo que todo desenvolvedor precisa considerar.

Quando se trata de resolver esse problema, duas abordagens se tornaram predominantes: webhooks e polling. Cada método oferece uma maneira única de buscar e entregar dados de um serviço para outro. Escolher um em detrimento do outro pode ter um grande impacto na eficiência, nas capacidades em tempo real e na experiência geral do usuário do seu aplicativo. Este artigo vai comparar webhooks vs. polling, analisar as vantagens e desvantagens de cada abordagem e discutir quando usar qual.

O que é polling?#

Polling (frequentemente referido como API polling) é o processo em que um cliente solicita dados específicos em intervalos regulares (digamos, a cada x segundos), e o servidor responde com os dados solicitados.

Pense nisso como perguntar "Há novos dados?" em intervalos regulares. Polling pode ser implementado via solicitações HTTP, onde o cliente envia uma solicitação GET ao servidor e o servidor responde com os dados solicitados.

Imagine que João criou um produto de documentação de IA chamado Doc.AI e usa Logto para gestão de identidade dos usuários.

Francisco é um usuário que se cadastrou no produto de João e criou sua própria conta pessoal. Um dia, Francisco entra em um workspace criado por seu amigo David. Naquele momento, João quer enviar um e-mail para Francisco pedindo para ele ativar a autenticação multifator (MFA) para aumentar a segurança da conta antes de João conceder-lhe acesso a recursos confidenciais adicionais.

O backend do produto de João precisa constantemente fazer polling nas APIs relevantes para saber quando Francisco entrou no workspace de David.

O que é webhook?#

Um webhook (ou "callback HTTP") é um mecanismo de comunicação de dados em tempo real, no qual o servidor envia dados para o cliente quando um evento ocorre. Em vez de o cliente solicitar dados, um webhook os envia automaticamente para o cliente sempre que há uma atualização.

Pense nisso como uma caixa de entrada para o seu aplicativo. Quando certos eventos acontecem - por exemplo, um novo usuário se registra ou um pagamento é realizado - um webhook enviará uma mensagem para a caixa de entrada para informar ao seu aplicativo o que está acontecendo.

Vamos continuar com o nosso exemplo do Doc.AI que usamos anteriormente para explicar polling. Aqui está como o diagrama de sequência se parecerá se estivermos usando webhooks para descobrir se Francisco entrou no workspace de David:

Diferenças importantes#

• Origem da solicitação Polling é inicializado pelo cliente (no nosso exemplo, Doc.AI é o cliente e Logto é o servidor) e webhook é acionado por evento e iniciado pelo servidor.
• Consumo de recursos Polling é um desperdício de recursos computacionais porque envia solicitações em intervalos regulares, resultando em baixa eficiência de recursos computacionais. Por outro lado, webhook é iniciado pelo servidor "sob demanda". Em comparação com polling, tanto o cliente quanto o servidor consomem muito menos recursos.
• Tempo Polling é iniciado pelo cliente, então o cliente pode controlar o tempo da aquisição de dados; no entanto, webhook é iniciado pelo servidor, e o cliente só pode receber e processar os dados. No entanto, devido aos diferentes mecanismos dos dois, webhook pode alcançar sincronização de dados em tempo real, o que não pode ser alcançado pelo polling.

Qual escolher?#

Com base nos mecanismos de polling e webhooks, a prática comum é escolher polling apenas quando os dados são frequentemente atualizados e os requisitos em tempo real para os dados não são rigorosos. Em outros casos, webhooks seriam uma escolha melhor.

No entanto, ao optar por usar webhooks, os desenvolvedores devem prestar atenção aos seguintes pontos:

1. Se o sistema é altamente dependente dos dados adquiridos, é necessário considerar ter um plano de contingência para adquirir dados quando o webhook falhar e os dados não puderem ser sincronizados, incluindo, mas não se limitando a polling ou exigindo que o webhook tenha um mecanismo de reenviar, etc.
2. No endpoint do lado do cliente que recebe os webhooks, deve-se aplicar a verificação do segredo da API e da assinatura do conteúdo, etc., para evitar que hackers ataquem o cliente falsificando o webhook.
3. Como o webhook pode enviar solicitações duplicadas, é necessário um processamento correspondente nesse momento para evitar duplicação e inconsistência de dados.

Logto, como uma solução de identificação de usuários extremamente popular, oferece inúmeros cenários de webhook e excelente segurança. Usando Logto como o sistema de identidade do seu produto, ele pode ser facilmente integrado e se encaixar em vários cenários de aplicação.