diferencias entre webhook y websocket

webhooks (2)

Siempre he querido hacer un chat 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 rendí y no lo he intentado en 10 años. Pero recientemente me enteré de webhooks y websockets. Y ambos parecen ser una forma de hacerlo, pero realmente no entiendo la diferencia. Alguien puede explicar?

Webhooks

Webhooks son para la comunicación de servidor a servidor. Trabajan en un servidor diciéndole a otro servidor que desea que los datos se envíen a una determinada URL cuando algo sucede.

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

Websockets son (generalmente) para la comunicación del servidor al navegador. El servidor aloja un servidor websocket y los clientes pueden abrir una conexión a ese servidor. Esto es popular ahora sobre todo porque es más rápido y tiene menos recursos que las formas más antiguas de resolver el problema, como el COMET long-polling .

Es posible conectar 2 servidores utilizando websockets , pero eso no suele ser para lo que se utilizan.

La confusión

Aunque uno de estos es (exclusivamente) servidor-servidor y uno es (en su mayoría) servidor-navegador, estas tecnologías a menudo se discuten en los mismos lugares, casi como si estuvieran resolviendo los mismos problemas. Si busca la cadena lo suficientemente alta, verá que ambos resuelven el problema de la comunicación en "tiempo real", pero resuelven diferentes aspectos de este problema de maneras 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, podría proporcionar una API de webhook o una API de websocket . Ambos permiten que el tercero obtenga actualizaciones rápidamente:

Si elige webhooks, ese tercero todavía tendrá que encontrar una manera de impulsar los cambios que les está diciendo a los navegadores de sus clientes.
Si proporciona una API de websocket, el tercero puede configurar su sitio para que cada uno de sus usuarios se conecte directamente a su API de websocket, y sus servidores tienen que hacer menos trabajo.

Aquí hay información adicional para elegir entre webhooks y websockets.

Las comunicaciones de servidor a servidor a través de websockets se han hecho populares con una nueva generación de aplicaciones de chatbot. Ahora, muchos chatbots que se ejecutan en websockets proporcionan una ventaja principal de no requerir una URL pública para los robots internos y privados. 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 servidor de seguridad, considere los websockets. Algunas compañías requieren una revisión de seguridad de la información antes de abrir tales conexiones.

Webhooks

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