Webhooks vs. polling

Quando criamos aplicações Web, muitas vezes temos vários serviços. Na grande maioria dos casos, eles consistem em muitos serviços Web diferentes a trabalhar em conjunto. Neste tipo de aplicação Web que consiste em vários serviços, como transmitir dados é algo que todo desenvolvedor precisa considerar.

Quando se trata de resolver esse problema, duas abordagens se tornaram convencionais: webhooks e polling. Cada método oferece uma maneira única de buscar e entregar dados de um serviço para outro. Optar por um em detrimento do outro pode ter um grande impacto na eficiência da sua aplicação, nas capacidades em tempo real e na experiência geral do utilizador. Este artigo irá comparar webhooks vs. polling, analisar as vantagens e desvantagens de cada abordagem, e discutir quando usar cada uma.

O que é polling?#

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

Pense nisso como perguntar, "Há novos dados?" em intervalos regulares. O polling pode ser implementado via pedidos HTTP, onde o cliente envia um pedido GET ao servidor, e o servidor responde com os dados solicitados.

Imagine que o João construiu um produto de documentação de IA chamado Doc.AI e utiliza o Logto para a gestão de identidade de utilizadores.

O Francisco é um utilizador que se inscreveu no produto do João e criou a sua própria conta pessoal. Um dia, o Francisco junta-se a um espaço de trabalho criado pelo seu amigo David. Nesse momento, o João quer enviar um email para pedir ao Francisco que ative a Autenticação de Múltiplos Fatores (MFA) para aumentar a segurança da sua conta antes de conceder-lhe acesso a recursos adicionais sensíveis.

O backend do produto do João precisa de consultar constantemente as APIs relevantes para saber quando o Francisco se junta ao espaço de trabalho do David.

O que é webhook?#

Um webhook (ou seja, "callback HTTP") é um mecanismo de comunicação de dados em tempo real, onde um servidor envia dados a um cliente quando ocorre um evento. Em vez de o cliente solicitar dados, um webhook entrega-os ao cliente sempre que há uma atualização.

Pense nisso como uma caixa de entrada para a sua aplicação. Quando certos eventos ocorrem – por exemplo, um novo utilizador se inscreve ou um pagamento é realizado – um webhook deixará uma mensagem na caixa de entrada para informar a sua aplicação sobre o que está a acontecer.

Vamos continuar com o exemplo do Doc.AI que usamos anteriormente para explicar o polling. Aqui está o que o diagrama de sequência pareceria se estivermos a utilizar webhooks para descobrir se o Francisco se juntou ao espaço de trabalho do David:

Diferenças importantes#

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

Qual devo escolher?#

Com base nos mecanismos de polling e webhooks, a prática comum é escolher o polling apenas quando os dados são frequentemente atualizados e o requisito de tempo real para os dados não é rigoroso. Nos outros casos, o webhook seria uma escolha melhor.

No entanto, ao optar por usar webhooks, os desenvolvedores precisam prestar atenção às seguintes preocupações:

1. Se o sistema é muito dependente dos dados adquiridos, é necessário considerar um plano de backup para adquirir dados quando o webhook falha e os dados não podem ser sincronizados, incluindo mas não se limitando a polling ou exigir que o webhook tenha um mecanismo de reenvio, etc.
2. No endpoint do lado do cliente que recebe webhooks, a verificação de segredo da API e assinatura de conteúdo, etc., deve ser aplicada para evitar que hackers ataquem o cliente fazendo-se passar pelo webhook.
3. Como o webhook pode enviar pedidos duplicados, é necessário um processamento correspondente neste momento para evitar a duplicação de dados e inconsistências.

O Logto, como uma solução de identificação de utilizador tremendamente popular, oferece uma diversidade de cenários de webhooks e excelente segurança. Utilizar o Logto como o sistema de identidade dos seus produtos permite uma fácil integração e adequação a vários cenários de aplicação.