Uma página de pedido pode precisar de uma atualização ao mesmo tempo que o seu banco de dados. Um webhook pode acionar a alteração no banco de dados. Seu servidor pode então publicar o estado resultante para as telas conectadas.
Bird Realtime entrega atualizações por WebSockets.
O que são canais, membros e conexões?
Um canal agrupa assinaturas. Uma conexão é um WebSocket aberto. Um membro é uma identidade autenticada compartilhada com outros assinantes.
Um canal presence compartilha quais membros estão inscritos. Um membro pode usar várias conexões, como abas separadas do navegador.
Bird cria um canal quando a primeira conexão se inscreve e o remove após a última sair. Você publica no nome do canal sem criar um recurso de canal separado.
Cada conexão recebe um identificador. Seu backend o utiliza para aprovar uma assinatura privada. Uma publicação pode excluir essa conexão para evitar ecoar a própria atualização.
Se um membro abre três abas, essas abas podem criar três conexões sob uma única identidade de membro. O presence reporta a entrada do membro na primeira conexão e a saída após o fechamento da última conexão. Fechar a aba do meio, portanto, não remove esse membro da lista.
Quem pode se inscrever?
O prefixo do canal determina se uma assinatura precisa de autorização do seu backend.
Você escolhe um nome de canal Bird de 1 a 164 caracteres, usando letras, dígitos e _ - = @ , . ;. Inclua o prefixo nesse comprimento para que um nome privado gerado fique dentro do limite.
| Prefixo do nome | Acesso |
|---|---|
| Sem prefixo private ou presence | Público para clientes que possuem a app key. |
private- | Seu backend aprova e assina cada assinatura. |
presence- | Seu backend aprova a assinatura e fornece a identidade de membro compartilhada com os assinantes. |
private-encrypted- | Acesso privado com conteúdo de eventos criptografado usando uma chave que você controla. |
A app key aparece no código do cliente, então um nome de canal público obscuro não protege dados confidenciais. Mantenha o app secret no seu servidor e use-o para assinar aprovações de assinatura.
Para uma assinatura privada, o cliente envia seu identificador de conexão e o nome do canal para o seu endpoint de autorização. Seu servidor verifica o acesso antes de retornar a assinatura. Esse endpoint autoriza o acesso. Ele não recebe cada evento publicado como um webhook faria.
O que essa diferença significa na prática?
Use webhooks para trabalho recuperável no seu servidor. Use pub/sub para atualizações em clientes conectados.
Um webhook Bird envia um evento para um endpoint HTTPS que você opera. As tentativas cobrem aproximadamente 27,5 horas, com intervalos ajustados por variação aleatória, sobrecarga do receptor e atrasos solicitados. Essa janela dá ao seu receptor tempo para se recuperar. A reprodução de eventos perdidos pode recuperar entregas que permaneceram sem sucesso.
Um canal Realtime envia o evento publicado para os clientes inscritos. Um cliente desconectado pode perdê-lo. Um canal de cache pode fornecer o evento mais recente a um novo assinante enquanto esse evento permanecer em cache. Ele não mantém o histórico de eventos intermediários.
Mantenha o processamento confidencial do lado do servidor atrás do seu receptor de webhook. Publique apenas o estado que os clientes autorizados do canal podem ver.
Os tipos de evento de webhook vêm do catálogo do Bird, como email.delivered. Com Realtime, você escolhe o nome do evento da sua aplicação ao publicar. O nome event aceita de 1 a 200 caracteres. Os prefixos bird: e bird_internal: são reservados e não podem nomear os eventos da sua aplicação.
Os clientes também recebem eventos de protocolo sobre sucesso de assinatura, mudanças de membros e contagens de conexão. Esses eventos descrevem a conexão ou o canal em si, e não o pedido ou a mensagem da sua aplicação.
Como usá-los juntos?
Use o evento armazenado do webhook para gerar uma atualização Realtime para clientes conectados.
Receba o evento de negócio no seu servidor. Atualize o estado durável antes de publicar. Em seguida, publique o estado de que os clientes conectados precisam.
Para uma página de pedido, o webhook pode acionar uma atualização no banco de dados. Seu servidor então publica o estado atualizado do pedido para que a página do cliente mude sem precisar recarregar.
Mantenha o estado do banco de dados legível após a reconexão, pois um cliente desconectado pode perder publicações. Webhooks, polling ou streaming compara as opções de recuperação.
O Realtime também tem seus próprios webhooks para ocupação de canal e chegadas ou saídas de membros. Configure-os pelo dashboard em vez da API pública de webhooks.
Visão geral do Realtime aborda conexões de clientes. Webhooks aborda solicitações entregues ao seu servidor.
Em resumo
Um canal pode ter muitos assinantes.
Uma solicitação de webhook vai para um único endpoint registrado. Uma publicação vai para os clientes inscritos no canal.
Assinaturas privadas precisam de aprovação do backend.
A app key aparece no código do cliente. Os prefixos private e presence exigem uma assinatura do seu servidor.
Membros podem ter várias conexões.
Um membro usando três abas entra no presence na primeira conexão e sai após o fechamento da última conexão.
Combine recuperação de entrega com uma visualização conectada.
Use a recuperação de webhook para eventos do servidor e o estado armazenado para restaurar uma visualização Realtime após desconexão.