spinner

El Event Driven, no solo es disparar un evento. Es que cuando se ejecuta el evento, el Publisher (el que dispara el evento) provea información extra.

Probablemente has oído hablar del mundo de REST y el paradigma de la comunicación síncrona. En la mayoría de los casos, Internet en general funciona de forma síncrona. Un ejemplo simple es cuando tú entras a alguna página en Internet, el navegador hace una petición a un servidor y éste responde con el contenido que has pedido. A esta comunicación donde hay que esperar una respuesta se le cataloga como síncrona, y si sólo se envía la petición y el servidor no resuelve nada se da por hecho que será asíncrono y que en algún momento el servidor lo atenderá.

En esta nueva era es necesario que la información se propague mucho más rápido, esto implica, no esperar la confirmación del servidor.

Podemos definir la comunicación asíncrona como aquella que no sucede en el mismo tiempo. Es decir el receptor atenderá el mensaje del emisor en un tiempo posterior a recibirlo, así el emisor podrá ir realizando otras tareas sin necesidad de esperar que la petición sea atendida. Por ejemplo enviar un email y que el receptor lo reciba 5 minutos después o más porque el servidor atendía otras entregas.

¿Cómo funciona el Event Driven?

Se puede decir que “disparamos un evento” para informar que algo pasó, y nos olvidamos de eso porque ya no es responsabilidad del que dispara el evento asegurarse de que se entregue el mensaje del evento. Aquí sumamos otro concepto importante pues ese disparo o llamada es “asíncrono” pues no esperamos a que se complete la tarea sino que damos por hecho que en algún momento alguien lo recibirá.

Algunos ejemplos de comunicación por eventos son:

  • Un cliente hace una transferencia electrónica. Una vez realizada, se lanza un evento de notificación push o un email de confirmación y la transferencia no espera a que la notificación se entregue sino que continúa normalmente sin demorar la petición de transacción.
  • ¡Tienes un nuevo seguidor en Instagram!
  • Tu Tesla se está quedando sin batería y te manda una notificación push para que lo recargues (genial ¿no?)

Pero no sólo es disparar un evento y ya. Bueno sí, pero pasan más cosas. Hay una parte importante en el proceso asíncrono. Cuando se ejecuta el evento, el Publisher (el que dispara el evento) provee información extra, por ejemplo, si tu Tesla se está quedando sin energía, el evento puede proveer: la cantidad de energía restante, un aproximado de cuántos kilómetros te quedan con la energía restante y quizá la estación de recarga más cercana.

A este enriquecimiento le llamaremos “event payload o message payload”. Posteriormente, el payload será entregado a la aplicación que está suscrita a este tipo de evento (subscriber).

A este paradigma se le da el nombre de Event Driven Architecture (EDA’s).

Conceptos de EDA’s

En la siguiente imagen verás a los actores principales de EDA.

Event-Driven

Publisher: Es la aplicación que dispara el evento al Broker, notificando que algo ha pasado.

Message: Es la información que los publicadores envían al Broker para que el Broker lo comunique a los suscriptores.

Broker: Es la pieza de arquitectura que se encarga de recibir y entregar los mensajes a las aplicaciones suscritas. Ejemplos de Brokers son RabbitMQ, Apache Kafka, Solace.

Subscriber: Es la aplicación que conecta con el Broker. Mantiene comunicación mediante un canal o tópico para escuchar cierto tipo de eventos, es decir está suscrito a esos eventos y se mantiene escuchando para cuando el Publisher envía un mensaje.

Channel: En el diagrama no aparece el canal pero no significa que no exista. El canal es por donde el Publisher envía el mensaje al subscriber, recuerda que hay varios subscriptores escuchando un tipo de evento que es el canal (e.g, password_reset) así que sólo un tipo de mensaje debería enviarse por este canal. El canal no es un concepto común en el EDA’s por lo que se le puede encontrar también con otros nombres como topics, routing keys, paths, event types e incluso otros.

Una analogía son los canales de la televisión o radio, el mensaje sólo llega a los subscribers si se está en un canal determinado, aunque los subscribers en este caso pueden estar escuchando varios canales.

Diseño: El diseño cobra gran importancia y vale la pena invertir en esta fase debido a lo siguiente. Existen especificaciones para diseñar un evento o API asíncronas. Al tener un diseño que es machine-readable nos permite automatizar ciertas tareas como: crear documentación en un portal como un catálogo de eventos, crear interfaces de los objetos que usaremos en programación, o con la ayuda de frameworks, levantar servicios como:

  • Logs
  • Mockup servers
  • Herramientas de testing
  • Validaciones de los mensajes
  • Aplicar políticas de tu API management después de llegar a tu broker
  • Servicios listos para hacer deploys con Kubernetes.

¿Qué es Spec AsyncAPI 2?

Según lo indica AsyncAPI en su spec:

“AsyncAPI es una iniciativa de código abierto que busca mejorar el estado actual de las arquitecturas dirigidas por eventos (EDA). El objetivo es que trabajar con EDA sea tan fácil como trabajar con API REST. Eso va desde la documentación hasta la generación de código, desde el descubrimiento hasta la gestión de eventos. La mayoría de los procesos que aplicamos a nuestras API REST hoy en día también serían aplicables a nuestras API asíncronas o controladas por eventos.”

Veamos un ejemplo sencillo de una definición de un evento con la especificación de AsyncAPI 2.0.0.

Event-Driven

Algo importante es que la especificación AsyncAPI 2.0.0 es machine-readable y es agnóstica al protocolo por lo que no importa si tu evento funciona con MQTT, WebSockets, Kafka (maneja su propio protocolo), HTTP o cualquier otro.

Las definiciones se pueden dividir en otros archivos para que puedas reutilizar definiciones comunes como por ejemplo la de un usuario.

El diseño de APIs da más para hablar, pero será en otro artículo donde profundicemos más.

¿Y el futuro de EDA’s?

Los eventos son cada vez más usados en IoT, debido a que proveen un alto valor en los productos al mantener informados a los suscriptores sobre lo que está pasando en todo momento.

Imagina que compras boletos de avión, e inmediatamente recibes una notificación con tus boletos y un evento en Google calendar; o una notificación al recibir tu nómina; o un correo de ofertas el fin de semana en tus tiendas favoritas. Estos casos pueden ser notificaciones por cualquier medio como email, push/web notificaciones, SMS o comandos incluso streamings de videos.

Un dato interesante de la demanda es que actualmente la información en tiempo real de eventos que se intercambia es de alrededor de 7 Zettabytes ¡¡Son 7000 millones de terabytes!! Los pronósticos son que este número crecerá exponencialmente en los próximos años.

En la siguiente gráfica se aprecia el crecimiento de información en tiempo real que se ha transmitido y su crecimiento con una proyección hasta 2025.

Event-Driven

*Source: IDC seagate data age 2025

EDA’s se convertirá en un área de estudio muy importante en un futuro, así como todo lo que hay a su alrededor: protocolos de comunicación, nuevos paradigmas de APIs, compresión de datos, Big Data, complejidad de algoritmos también.

Enlaces de ayuda:

Protocolo MQTT
Kafka
Protocolo HTTP
Spec async API
Seagate post

Fuente de imagen principal: Pexels

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?

Utilizamos cookies propias y de terceros para mejorar nuestros servicios, brindarle una grata experiencia y mostrar a los usuarios publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando por este sitio web, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información accediendo a nuestra política de cookies aquí.