En el capítulo anterior analizábamos como mediante el Polling, era posible sondear los cambios de un componente externo mediante una serie de consultas repetitivas, pero que pasa cuando necesitamos hacer todo lo contrario, y en lugar de estar preguntado cada rato por nuevas actualizaciones, sea el otro sistema quien nos notifique al instante cuando un nuevo cambio sucede, pasando de una arquitectura proactiva a una pasiva.
Problemática
En la sección pasada analizábamos que el Polling es un patrón inadecuado cuando tenemos grandes cantidades de Requesters, ya que cada uno comienza a realizar consultas repetitivas que puedan afectar el rendimiento de nuestra aplicación.
Este problema se acentúa cuando tenemos cientos o miles de Requesters interesados en saber si existen nuevas actualizaciones, lo que puede llegar a colapsar al Provider por las miles o millones de peticiones que se podrían acumular durante todo el día, lo que hace que el Polling sea una solución inaceptable.
Para comprender esta problemática imaginemos el clásico escenario de la pareja con sus hijos que van por la carretera y a los 10 minutos de haber comenzado el viaje los niños comienzan a preguntar cada 5 minutos, ¿Cuánto falta para llegar?, ¿Ya vamos a llegar? Quizás esta comparación es un poco burda, pero en ese mismo escenario, imagina que vas en un camión escolar y todos los niños comienzan a preguntar y tú necesitas estar concentrado en el camino. Seguramente después de un rato te vas a volver loco respondiendo a cada niño que pregunte, y en una de esas te puede distraer y causar un accidente.
Cómo funciona el Polling.
El Polling es algo similar, cuando las preguntas son pocas es fácil controlarlas, pero a medida que estas suben de intensidad se va haciendo imposible controlarlas, lo que hace que, nuestra operación se vea comprometida por la necesidad de responder a todos los que pregunta. En este sentido, lo niños serían los Requester, mientras llegar a tu destino es la operación, la cual no se puede detener por nada y si por estar respondiendo a los niños nuestra operación se puede ver comprometida, entonces quiere decir que algo anda mal.
Solución
Una vez que sabemos que el Polling no es la mejor solución para resolver este tipo de problemas pasamos a analizar cuál sería la mejor solución.
Basado en el ejemplo anterior, que pasaría si en lugar de responder a los niños cada vez que pregunte, cambiamos la estrategia y mejor usamos un megáfono para decirles a los niños cuanto falta cada vez que vemos un cartelón en la carretera que nos indica los kilómetros restantes. De esta forma los niños podrán saber cuánto falta para llegar de una forma regular y no distraerá mucho al conductor, pues solo tendrá que hacer unos cuantos anuncios en comparación con responder a cada niño.
Los Webhook trabajan de una forma similar, pues la responsabilidad de notificar los cambios relevantes pasa a ser la responsabilidad del Provider, pero el Requester deberá contar con un mecanismo para recibir estas notificaciones. De esta forma, el Provider notificará cuando alguna actualización relevante suceda, pero no le interesará que haga el Requester con ella.
Cómo funciona un Webhook
En el caso de una aplicación real, lo primero que se tiene que hace es definir lo eventos de la aplicación que deberán ser notificados a los interesados, de esta forma, es el Provider el que determina que información será notificada y cual no, por otro lado, los Requester se tendrán que suscribir a los eventos del Provider, para esto, será necesario que el Requester le indique al Provider que eventos quiere recibir y proporcionarle una dirección (URL) donde el Provider deberá enviar las notificaciones.
Este registro se hace mediante los mecanismos que proporciones el Provider, los cuales pueden ser diversos, como una página web, un servicio web, REST, etc. En realidad, el patrón no determina la forma en que se debe de hacer este registro.
Una vez registrado, el Requester comenzará a recibir las notificaciones de los eventos a los que se ha registrado, directamente a la URL que configuró. Estas notificaciones tienen la ventaja de que pueden ser muy rápida, incluso con unos pocos segundos de diferencia entre que el evento se disparó y el Requester recibe la notificación.
Diagrama de secuencia del webhook
En el diagrama anterior podemos observar cual es la secuencia de pasos de un Webhook, el cual se lee de la siguiente forma:
Un usuario administrador realiza el registro del Requester para recibir notificaciones.
El Provider retorna con la confirmación del registro.
Un nuevo usuario entra a la aplicación del Provider y realiza una nueva compra.
El Provider procesa la compra y genera un nuevo evento que requiere ser notificado.
El Provider busca en su registro para saber cuáles son los Requester interesados en ser notificados y les envía una nueva notificación por medio de la URL provista en el primer paso.
Algo a tomar en cuenta es que, las notificaciones no se envían precisamente a todos los Requester registrados, sino más bien, es necesario determinar por medio de los privilegios, quien tiene acceso a cierta información, por ejemplo, si es una aplicación donde varios clientes pueden acceder, no les vamos a mandar las notificaciones de información a la cual no deberían de tener acceso, entonces, tendríamos que tomar en cuenta esto en caso de que sea aplicaciones para múltiples clientes.
Conclusiones
Como hemos podido observar, lo Webhook son una excelente opción cuando necesitamos crear un mecanismo para notificar a otros componentes sobre los eventos producidos en nuestra aplicación, de esta forma, brindamos una mejor experiencia al evitar que los componentes externos tengan que estar preguntando por las actualizaciones a cada rato, y en su lugar, somo nosotros los que los notificamos.
Además, hemos analizado como el uso de los Webhook evitan el uso de los Polling, un patrón que puede afectar el performance a medida que el número de Requester aumenta, lo que hace que no sea una arquitectura escalable y que incluso, puede llegar a afectar la operación.
Acerca de este libro
Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.
¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:
