Siempre quise tener una charla en tiempo real.

Lo hice hace años en PHP + Ajax + Mysql y rompí mi servidor. Luego probé con Flash + un archivo de texto. Me di por vencido y no lo he intentado en 10 años. Pero recientemente escuché sobre webhooks y websockets. Y ambos parecen ser una forma de hacer eso, pero realmente no entiendo la diferencia. ¿Alguien puede explicarlo?

Webhooks

Los webhooks son para la comunicación de servidor a servidor. Funcionan mediante un servidor que le dice a otro servidor que quiere que los datos se envíen a una determinada URL cuando sucede algo.

Este artículo habla sobre algunos usos de webhooks en servicios populares. Esta organización habla mucho sobre su uso en el contexto de las API RESTful.

Websockets

Los Websockets son (generalmente) para la comunicación entre el servidor y el navegador. El servidor aloja un servidor websocket y los clientes pueden abrir una conexión a ese servidor. Esto es popular ahora principalmente porque es más rápido y consume menos recursos que las formas antiguas de resolver el problema, como el sondeo largo / COMET .

Es posible conectar 2 servidores mediante websockets , pero normalmente no es para eso que se utilizan.

La confusión

Aunque uno de estos es (exclusivamente) servidor-servidor y el otro es (en su mayoría) navegador-servidor, estas tecnologías a menudo se discuten en los mismos lugares, casi como si estuvieran resolviendo los mismos problemas. Si miras la cadena lo suficientemente alto, ves que ambos resuelven el problema de la comunicación en "tiempo real", pero resuelven diferentes aspectos de este problema de formas muy diferentes .

Una situación en la que puede haber una comparación directa es si está creando una API que será consumida por un servidor de terceros. En esa situación, puede proporcionar una API webhook o una API websocket . Ambos permiten que el tercero obtenga actualizaciones rápidamente:

• Si elige webhooks, ese tercero aún tendrá que encontrar una manera de impulsar los cambios que les está informando en los navegadores de sus clientes.
• Si proporciona una API de websocket, el tercero puede simplemente configurar su sitio para que cada uno de sus usuarios se conecte directamente a su API de websocket y sus servidores tengan que hacer menos trabajo.

A continuación, se ofrece información adicional para elegir entre webhooks y websockets.

Las comunicaciones de servidor a servidor a través de websockets se han vuelto populares con una nueva generación de aplicaciones de chatbot. Ahora, muchos chatbots se ejecutan a través de websockets con la ventaja principal de no requerir una URL pública para los bots privados internos. En este entorno, las siguientes son algunas pautas sobre cuándo considerar el uso de webhooks frente a websockets.

Websockets

• Si su aplicación es una aplicación de navegador, use websockets porque su aplicación no puede recibir webhooks.
• Si su aplicación es una aplicación de servidor que recibe mensajes de un servicio a través de Internet y no desea abrir su firewall, considere la posibilidad de utilizar websockets. Algunas empresas requieren una revisión de seguridad de la información antes de abrir dichas conexiones.

Webhooks

• Si la aplicación de su aplicación de servidor necesita realizar muchas suscripciones, prepárese para manejar el volumen de conexiones de websocket abiertas a su servidor ( consulte este artículo para conocer las conexiones de websocket de 1M ) o cambie a webhooks. Algunos chatbots populares han pasado de websockets a webhooks para mejorar la escalabilidad.
• Si su aplicación de servidor se ejecuta como una función en la nube en (AWS Lambda, Google Cloud Functions, etc.), use webhooks porque su aplicación no mantendrá abierta la conexión websocket.
• Si su aplicación de servidor se está ejecutando en el nivel gratuito de Heroku, use webhooks porque su Dyno se dormirá y deberá dormir durante 6 horas al día, a menos que le indique manualmente a su servidor que duerma.