Webhooks vs. sondeo

Cuando construimos aplicaciones web, a menudo tenemos múltiples servicios. En la gran mayoría de los casos, consisten en muchos servicios web diferentes que trabajan juntos. En este tipo de aplicación web que consiste en múltiples servicios, cómo transmitir datos es algo que todo desarrollador debe considerar.

Cuando se trata de resolver este problema, dos enfoques se han vuelto predominantes: webhooks y sondeo. Cada método proporciona una forma única de obtener y entregar datos de un servicio a otro. Elegir uno sobre el otro puede tener un gran impacto en la eficiencia de tu aplicación, en sus capacidades en tiempo real y en la experiencia general del usuario. Este artículo comparará webhooks vs. sondeo, analizará las ventajas y desventajas de cada enfoque, y discutirá cuándo utilizar cuál.

¿Qué es el sondeo?#

El sondeo (a menudo referido como sondeo de API) es el proceso en el cual un cliente solicita datos específicos a intervalos regulares (digamos, cada x segundos), y el servidor responde con los datos solicitados.

Piensa en esto como preguntar, "¿Hay algún dato nuevo?" a intervalos regulares. El sondeo se puede implementar a través de solicitudes HTTP, donde el cliente envía una solicitud GET al servidor y el servidor responde con los datos solicitados.

Imagina que John construyó un producto de documentación de IA llamado Doc.AI y utiliza Logto para la gestión de identidad de usuarios.

Frank es un usuario que se registró en el producto de John y creó su propia cuenta personal. Un día, Frank se une a un espacio de trabajo creado por su amigo David. En ese momento, John quiere enviar un correo electrónico a Frank para pedirle que active la Autenticación Multifactor (MFA) para mejorar la seguridad de su cuenta antes de que John le conceda acceso a recursos adicionales sensibles.

El backend del producto de John necesita sondear constantemente las API relevantes para saber cuándo Frank se une al espacio de trabajo de David.

¿Qué es un webhook?#

Un webhook (es decir, "callback HTTP") es un mecanismo para la comunicación de datos en tiempo real, donde un servidor enviará datos a un cliente cuando ocurra un evento. En lugar de que un cliente solicite datos, un webhook los envía al cliente cada vez que hay una actualización.

Piensa en esto como una bandeja de entrada para tu aplicación. Cuando ocurren ciertos eventos - por ejemplo, un nuevo usuario se registra o se realiza un pago - un webhook dejará un mensaje en la bandeja de entrada para que tu aplicación sepa lo que está sucediendo.

Continuemos con nuestro ejemplo de Doc.AI que utilizamos anteriormente para explicar el sondeo. Así es como se verá el diagrama de secuencia si estamos usando webhooks para averiguar si Frank se ha unido al espacio de trabajo de David:

Diferencias importantes#

• Origen de la solicitud El sondeo lo inicia el cliente (en nuestro ejemplo, Doc.AI es el cliente y Logto es el servidor) y el webhook se activa por un evento y lo inicia el servidor.
• Consumo de recursos El sondeo es un desperdicio de recursos computacionales porque envía solicitudes a intervalos regulares, lo que resulta en una baja eficiencia de los recursos computacionales. Por otro lado, el webhook es iniciado por el servidor "a demanda". En comparación con el sondeo, tanto el cliente como el servidor consumen muchos menos recursos.
• Cronometraje El sondeo es iniciado por el cliente, por lo que el cliente puede controlar el momento de la adquisición de datos; Sin embargo, el webhook es iniciado por el servidor, y el cliente solo puede recibir y procesar datos. Sin embargo, debido a los diferentes mecanismos de los dos, el webhook puede lograr una sincronización de datos en tiempo real, lo que no se puede lograr mediante sondeo.

¿Cuál debería elegir?#

Basado en los mecanismos de sondeo y webhooks, la práctica común es elegir el sondeo solo cuando los datos se actualizan con frecuencia y la necesidad de tiempo real no es estricta. En otros casos, los webhooks serían una mejor opción.

Sin embargo, al optar por utilizar webhooks, los desarrolladores deben prestar atención a los siguientes inconvenientes:

1. Si el sistema depende en gran medida de los datos adquiridos, es necesario considerar tener un plan de respaldo para adquirir datos cuando el webhook falla y no se pueden sincronizar los datos, incluyendo, pero no limitado a sondeo o requerir que el webhook tenga un mecanismo de reenvío, etc.
2. En el endpoint del lado del cliente que recibe webhooks, se deben aplicar la verificación de la clave secreta de la API y la firma del contenido, etc., para evitar que los hackers ataquen al cliente falsificando el webhook.
3. Dado que el webhook puede enviar solicitudes duplicadas, se requiere un procesamiento correspondiente en ese momento para evitar la duplicación de datos e inconsistencias.

Logto, como una solución de identificación de usuarios enormemente popular, ofrece muchas escenas de webhook y una excelente seguridad. Usando Logto como tu sistema de identidad de productos, puede integrarse fácilmente y adaptarse a diversas escenas de aplicación.