Sempre quis fazer um bate-papo em tempo real.

Eu fiz isso anos atrás em PHP + Ajax + Mysql e quebrei meu servidor. Então tentei com Flash + um arquivo de texto. Desisti e não tentei em 10 anos. Mas recentemente ouvi sobre webhooks e websockets. E ambos parecem ser uma maneira de fazer isso, mas eu realmente não entendo a diferença. Alguém pode explicar?

Webhooks

Webhooks são para comunicação de servidor para servidor. Eles funcionam por um servidor informando a outro servidor que deseja que os dados sejam enviados a um determinado url quando algo acontecer.

Este artigo fala sobre alguns usos de webhooks em serviços populares. Esta organização fala muito sobre como usá-los no contexto de APIs RESTful.

Websockets

Websockets são (geralmente) para comunicação de servidor para navegador. O servidor hospeda um servidor websocket e os clientes podem abrir uma conexão com esse servidor. Isso é popular agora principalmente porque é mais rápido e consome menos recursos do que as formas mais antigas de resolver o problema, como long-polling / COMET .

É possível conectar 2 servidores usando websockets , mas normalmente não é para isso que eles são usados.

A confusão

Mesmo que um deles seja (exclusivamente) servidor-servidor e o outro (principalmente) navegador-servidor, essas tecnologias são frequentemente discutidas nos mesmos lugares, quase como se estivessem resolvendo os mesmos problemas. Se você olhar para o alto da cadeia, verá que ambos resolvem o problema da comunicação em "tempo real", mas resolvem diferentes aspectos desse problema de maneiras muito diferentes .

Uma situação em que pode haver uma comparação direta é se você estiver construindo uma API que será consumida por um servidor de terceiros. Nessa situação, você pode fornecer uma API webhook ou uma API websocket . Ambos permitem que o terceiro obtenha atualizações rapidamente:

• Se você escolher webhooks, esse terceiro ainda terá que descobrir uma maneira de enviar as alterações que você está relatando para os navegadores de seus clientes.
• Se você fornecer uma API de websocket, o terceiro pode simplesmente configurar seu site para que cada um de seus usuários se conecte diretamente à sua API de websocket, e seus servidores tenham menos trabalho.

Aqui estão algumas informações adicionais para escolher entre webhooks e websockets.

A comunicação de servidor para servidor em websockets tornou-se popular com uma nova geração de aplicativos de chatbot. Agora, muitos chatbots executados em websockets fornecem a principal vantagem de não exigir uma URL voltada para o público para bots privados internos. Neste ambiente, a seguir estão algumas orientações sobre quando considerar o uso de webhooks em vez de websockets.

Websockets

• Se seu aplicativo for um navegador, use websockets porque seu aplicativo não pode receber webhooks.
• Se seu aplicativo for um aplicativo de servidor que recebe mensagens de um serviço pela Internet e você não deseja abrir seu firewall, considere websockets. Algumas empresas exigem uma revisão da segurança da informação antes de abrir tais conexões.

Webhooks

• Se o seu aplicativo de servidor precisa fazer muitas assinaturas, esteja preparado para lidar com o volume de conexões de websocket abertas para o seu servidor ( consulte este artigo para conexões de 1M de websocket ) ou mude para webhooks. Alguns chatbots populares mudaram de websockets para webhooks para melhorar a escalabilidade.
• Se seu aplicativo de servidor for executado como uma função de nuvem (AWS Lambda, Google Cloud Functions, etc.), use webhooks porque seu aplicativo não manterá a conexão de websocket aberta.
• Se seu aplicativo de servidor estiver rodando na camada gratuita do Heroku, use webhooks porque seu Dyno irá hibernar e deve hibernar por 6 horas por dia, a menos que você instrua manualmente seu servidor para hibernar.