Devo usar webhooks, polling ou streaming?

Uma atualização de pedido pode ter dois consumidores: seu banco de dados e o cliente acompanhando a página do pedido. Eles precisam de comportamentos de recuperação diferentes quando uma conexão cai.

Seu banco de dados precisa de um registro recuperável do evento. A página do cliente pode precisar apenas do estado mais recente do pedido após a reconexão.

Quais são as quatro opções?

Bird oferece webhooks, Realtime, um stream de eventos do dashboard e leituras API que você pode consultar por polling.

Use webhooks para receber eventos no seu servidor. Use Realtime para atualizar clientes conectados. O stream SSE envia alterações de recursos para uma sessão do dashboard. Polling permite que sua aplicação leia o estado de recursos em um intervalo programado.

Quando webhooks são a resposta certa?

Use webhooks quando seu servidor precisar agir sobre eventos e recuperar entregas perdidas.

Você registra um endpoint HTTPS acessível publicamente. Inscreva-o nos tipos de evento que você precisa. Seu receptor verifica a assinatura primeiro. Depois armazena o evento. Ele confirma a entrega antes de iniciar qualquer processamento demorado.

Bird faz até oito tentativas ao longo de aproximadamente 27,5 horas antes de ajustes de intervalo. Essa janela dá ao receptor tempo para se recuperar de uma interrupção. O reprocessamento de eventos perdidos oferece um caminho de recuperação adicional.

Faça deduplicação com base em webhook-id porque o mesmo evento pode chegar repetidamente. Compare os horários de ocorrência dos eventos antes de sobrescrever o estado, porque os eventos podem chegar fora de ordem.

Tentativas de reenvio de webhooks com falha cobre os limites de recuperação. Tratamento de duplicatas cobre como armazenar o evento com segurança antes de retornar sucesso.

Quando devo usar Realtime?

Use Realtime quando um navegador ou aplicação conectada precisar de atualizações à medida que seu servidor as publica.

Um canal é um destino nomeado ao qual clientes se inscrevem. Seu servidor publica um evento nesse nome, e os clientes inscritos o recebem pelas suas conexões. Isso pode atualizar uma página de pedido, uma conversa de chat ou um indicador de progresso sem recarregar a página.

Realtime não reproduz todos os eventos que um cliente desconectado perdeu. Mantenha o estado durável no seu banco de dados e restaure a visualização após reconectar.

Um canal de cache retém seu evento mais recente para novos assinantes enquanto esse valor em cache estiver disponível. Ele não mantém histórico de eventos. Se duas atualizações acontecerem enquanto um cliente estiver offline, o valor mais recente em cache não consegue recuperar a atualização intermediária.

A app key aparece no código do cliente, então um canal público pode ser lido por qualquer visitante que possua essa chave. Um canal que começa com private- exige que seu backend autorize a assinatura. Um canal presence- também compartilha as identidades dos membros inscritos.

Nomes de canais aceitam de 1 a 164 caracteres usando letras, dígitos e _ - = @ , . ;. O prefixo faz parte desse limite, então inclua-o ao validar um nome gerado.

Realtime também envia webhooks quando um canal ganha seu primeiro assinante ou perde o último. Webhooks de membros informam quais membros entraram ou saíram. Configure-os pelo dashboard. Publish/subscribe versus webhooks explica como os dois mecanismos funcionam juntos.

Bird tem um endpoint SSE?

Bird tem um endpoint SSE, getEventsStream, para sessões de dashboard autenticadas.

GET /v1/events/stream informa alterações em recursos API. Uma notificação identifica o tipo de recurso, o identificador e o horário de ocorrência para que o dashboard possa buscar os dados do recurso.

O endpoint aceita um cookie de sessão do dashboard. Ele não aceita uma chave API, então use webhooks ou polling para uma integração baseada em chave API.

Quando polling é a opção correta?

Use polling quando você precisar do estado de um recurso, não puder receber requisições de entrada ou não tiver um evento público para a alteração.

Use polling para verificar se uma operadora aprovou seu número toll-free para envio de mensagens de texto. Bird não tem um evento público de webhook para essa decisão de verificação. Leia a verificação em um intervalo programado por meio de bird sms tfn verifications get, ou da ferramenta de agente correspondente. A operação de comando está fora do bundle público API.

Polling também funciona em uma rede que permite requisições de saída mas não pode expor um receptor. Se você precisa apenas do estado atual, ler o recurso evita reconstruí-lo a partir de eventos anteriores.

Leituras e listagens consomem orçamentos de limitação de requisições por credencial atuante dentro de uma organização. Aguarde antes de fazer uma nova requisição após uma resposta HTTP 429. Ajuste o intervalo à rapidez com que sua aplicação precisa detectar uma alteração.

Webhooks, Realtime e limites de requisições cobrem a configuração para esses caminhos.

Qual devo escolher?

Escolha com base em quem consome a atualização e no que precisa sobreviver a uma desconexão.

1. Webhooks quando seu servidor precisar processar eventos com tentativas automáticas e recuperação de eventos perdidos.
2. Realtime quando telas conectadas precisarem de atualizações e puderem se recuperar a partir do estado armazenado após reconectar.
3. Polling quando você precisar do estado de um recurso, não puder expor um receptor ou não tiver um evento público.
4. O stream SSE para uma sessão de dashboard Bird autenticada.