AsyncAPI, ¿de qué estamos hablando?
Muchos de los que estaréis leyendo este artículo, os estaréis preguntando qué es AsyncAPI, o quizás lo hayáis empleado en algún proyecto, sin ser plenamente conscientes. Se trata de una especificación de código abierto, cuya primera versión emergió allá por el 2017 y se ha convertido en el estándar de la industria para definir APIs asíncronas o event-driven.
Si has trabajado con APIs HTTP, seguramente conozcas OpenAPI (anteriormente, Swagger), pues bien, AsyncAPI podría considerarse su homólogo en el mundo de las APIs dirigidas por eventos.
¿Para qué usarlo?
A continuación, detallaré varios puntos por los que podríamos utilizar AsyncAPI.
Definir un contrato
Uno de los objetivos principales de la especificación es describir nuestras APIs basadas en mensajes en un formato legible por la máquina. Dicha descripción debe ser agnóstica en cuanto a protocolo, es decir, debe funcionar sobre cualquiera de los protocolos que tenemos en mente: AMQP, MQTT, WebSockets, Kafka, etc.
Para conseguir este objetivo, se implementan los documentos AsyncAPI. Un documento AsyncAPI es un fichero en formato JSON o YAML, cuyo objetivo es describir las operaciones que una aplicación acepta. El conjunto de operaciones que acepta nuestra API y que se encuentran descritas en estos documentos JSON o YAML es lo que llamamos contrato. Un ejemplo de contrato podría ser el siguiente:
Este documento describe que una aplicación ‘mybookings.com’, permite a un consumidor suscribirse al canal ‘booking/notification’, y recibir mensajes sobre notificaciones de las reservas de alojamiento, que son producidos por la aplicación. Por otro lado, permite a un productor publicar mensajes en el canal ‘booking/search, proporcionando unos parámetros para la búsqueda de reservas. Cada mensaje tiene su propia representación, que se corresponde con el elemento payload.
Se ha hecho énfasis en los términos aplicación, consumidor, productor, canal y mensaje, porque son conceptos centrales a la hora de definir un API event-driven.
Una aplicación puede referirse a un microservicio, dispositivo IoT, un proceso batch, etc. los cuales pueden adoptar un rol de productor, consumidor o ambos. Un consumidor es cualquier tipo de aplicación que consume mensajes a partir de un canal. Un productor, por el contrario, es una aplicación que crea mensajes y los publica en un canal.
Por último, hablamos de canal y mensaje. Un canal se define como un componente direccionable, que es expuesto por un servidor para la organización de mensajes. El mensaje es el mecanismo central, por el que la información es intercambiada a través de un canal entre servidores y aplicaciones, y que consta de un payload y puede contener unas cabeceras. Hay un concepto que no se destacó anteriormente, pero que se ha mencionado en estas definiciones y es el de servidor, que no es más que un broker de mensajería que es capaz de enviar y recibir mensajes entre productores y consumidores.
Documentar el API
AsyncAPI proporciona diversas herramientas para la generación de documentación a nivel de compilación, en servidor y en cliente.
Generar código
Por otro lado, ya que los documentos AsyncAPI son una definición en formato legible por la máquina, pueden ser utilizados posteriormente para generar código (Javascript, Java, C#, etc), y para validar y aplicar políticas de gestión de API a los mensajes que el broker reciba.
Estandarización
Si estás familiarizado con OpenAPI, no te costará empezar con esta especificación, pues AsyncAPI ha sido creada para mantener el mayor grado de compatibilidad entre ambas. Al fin y al cabo, es probable que un sistema no utilice simplemente un enfoque de arquitectura EDA, y es por eso, que el objetivo de AsyncAPI es que cualquier desarrollador use esta especificación junto con sus definiciones OpenAPI, GraphQL o gRPC.
Siguientes pasos
En el próximo artículo mostraré un ejemplo práctico que muestra cómo utilizar varias herramientas de las que proporciona el ecosistema AsyncAPI.
Conclusión
AsyncAPI es una especificación de referencia en la industria software, respaldado por empresas como Axway, Adidas o Slack, entre otras, lo que le han convertido en el estándar de facto de la industria, gracias a diversas características como son su enfoque de protocolo agnóstico, su extensibilidad debido a su naturaleza open-source y la elevada productividad que proporciona, gracias a su similitud con especificaciones como OpenAPI y a la amplia variedad de herramientas que ofrece a su disposición. Estos factores entre otros, hacen que el futuro de esta especificación sea prometedor.