Header Ads Widget

Ticker

6/recent/ticker-posts

AsyncAPI: ¿Estándar de la industria de 2020 para API de mensajería?

 


La industria se compone de una amplia variedad de implementaciones, soluciones y marcos. Dentro de esta nube de sistemas competidores, la API de mensajería lucha por una sección muy específica, a menudo de nicho, de los esfuerzos de desarrollo. La búsqueda para encontrar un estándar sólido para este tipo de API, entonces, es un esfuerzo continuo.

Una respuesta a la pregunta de una especificación de definición estandarizada para tales API es AsyncAPI . AsyncAPI está diseñado específicamente para ofrecer definiciones extensibles, potentes y transformables para las API de mensajería, pero ¿es una buena solución en la práctica? Y más concretamente, ¿por qué es necesario un estándar?

Este artículo sigue a una presentación de Francisco Méndez de AsyncAPI . Mira aquí:

La necesidad de un estándar industrial

“Nosotros, como industria, necesitamos un lenguaje común. Imagínese si no tuviéramos cosas como HTTP. ¿Te imaginas la web actual sin HTTP? Eso sería un lío, eso sería un lío loco, el navegador tendría que implementar diferentes tipos de protocolos. […] Uno de los propósitos principales de AsyncAPI era hacerlo legible por máquina. Puede tener documentación legible por humanos, que puede ser muy agradable y hermosa, y puede explicar las cosas de una manera agradable, pero que no puede ser analizada por una máquina, que no se puede compartir con otra persona en el mundo que no habla. el mismo idioma. Entonces, necesitamos algo que se pueda intercambiar ".

Antes de sumergirnos en AsyncAPI específicamente, debemos sentar las bases sobre las que existe. La razón por la que AsyncAPI es tan importante se reduce a la necesidad de un lenguaje común. En su forma más básica, el lenguaje define cómo nos comunicamos. Esto es cierto en términos de nuestros idiomas hablados, pero lo mismo sigue siendo cierto cuando discutimos el "lenguaje" de las estrategias técnicas, especificaciones, marcos y modos de comunicación.

La elección de utilizar diferentes enfoques que no coinciden, o que a veces son completamente incompatibles, puede resultar en una gran cantidad de confusión que puede ser más dañina que cualquier otra restricción con la que se pueda encontrar el proyecto promedio. Este es en gran parte el argumento detrás de la estandarización en el espacio tecnológico: que el uso de enfoques estándar ofrece mejores beneficios durante un período de tiempo más largo con menos dolores de cabeza. Podemos aislar algunos de estos beneficios para demostrar el valor de tal enfoque de estandarización.

Relacionado: AsyncAPI vs.OpenAPI: ¿Cuál es la diferencia?

Beneficios de la estandarización

Primero, la adopción de estándares puede resultar en la generación de herramientas estandarizadas más efectivas. Cuando usa diferentes enfoques, este valor se pierde: tener diferencias entre los enfoques y las metodologías de API da como resultado herramientas propietarias y los problemas que surgen al intentar unir esas herramientas en un enfoque común.

En segundo lugar, hay un argumento que puede formularse desde una posición puramente de costo-beneficio. El costo de pasar de un enfoque a otro y adaptarse a una nueva metodología en lugar de utilizar una solución estándar probada puede ser bastante caro. Este costo no es solo en términos de valor económico, sino en términos de horas y la cantidad de inversión en conocimiento que conlleva la creación de dicho entorno y aplicación.

Si bien hay una serie de cuestiones adicionales que pueden plantearse, quizás el argumento más fuerte en contra de los enfoques patentados es la dificultad de integración y cooperación. No tener una metodología común significa que tiene una peor integración entre grupos dispares en su organización interna, esfuerzos de cooperación menos efectivos con diferentes socios externos a la integración y, en última instancia, dificultad en la comunicación en todos los niveles.

Por todas estas razones, la adopción de un estándar es algo que debe verse como lo que es: un beneficio neto para la organización. Esto no quiere decir que se deban ignorar otras innovaciones o que la industria simplemente deba elegir un estándar con exclusión de todo lo demás; todo lo que significa es que la industria debe elegir un enfoque general para aplicaciones específicas si quiere madurar y cosechar los beneficios. beneficios de la estandarización.

Legibilidad mecánica frente a humana

Sin embargo, aquí hay una advertencia: incluso si estamos de acuerdo en un marco o un lenguaje, en esencia, también hay un problema subyacente en términos del método de entrega. Existen fundamentalmente dos modos o métodos de comunicación: legible por máquina y legible por humanos. Incluso si todo el mundo de la tecnología determinara que iban a utilizar el Lenguaje # 1, la documentación sobre estos esfuerzos, la forma en que se hablaban entre sí, la forma en que se diseñaron las soluciones a su alrededor y el método fundamental por el cual se entenderían sería igualmente importante, y se dividiría en gran medida en uno de estos dos campos.

La legibilidad por máquina es esencialmente un modo de comunicación cuyas prioridades funcionan sobre la forma. Los lenguajes legibles por máquina dan prioridad a la organización de los datos en un formato que sea legible y transformable por las máquinas, con la expectativa de que las máquinas interactúen y reaccionen con datos propios en un formato legible por máquinas.

Si bien estos datos son difíciles de comprender o utilizar para los usuarios finales, esto es un artefacto de su diseño: el código no está destinado a usuarios humanos, está destinado a máquinas. Esto a menudo da como resultado un código más conciso con menos hinchazón (aunque, como la mayoría de los beneficios discutidos aquí con respecto a la legibilidad, esto no está asegurado). Un ejemplo de este tipo de datos sería JSON, que a menudo es bastante complejo, si no muy detallado y detallado.

La legibilidad humana, por otro lado, es un código diseñado específicamente para priorizar la interacción humana y la comprensibilidad. En este caso, el código está diseñado para humanos y, como tal, normalmente (aunque, de nuevo, no siempre) tiene una mayor hinchazón en forma de aclaración de datos y contexto. Un ejemplo de este tipo de datos sería YAML, que tiene mucha más claridad en una estructura legible por humanos.

Cabe señalar que los elementos de legibilidad discutidos anteriormente no siempre son constantes. En teoría, un formato legible por máquina se deshace del formato que tiene un lenguaje legible por humanos. En realidad, algunos lenguajes legibles por humanos son más concisos que otros lenguajes legibles por máquina. Las compensaciones en tamaño, eficiencia, etc. no siempre están aseguradas, pero en general, garantizar la compatibilidad con ambos métodos es mucho más efectivo que elegir un enfoque único.

¿Qué es AsyncAPI?

AsyncAPI es una especificación diseñada específicamente para describir microservicios controlados por eventos. Por todas las razones mencionadas anteriormente, muchos desarrolladores han requerido un formato estandarizado; AsyncAPI, entonces, es la respuesta propuesta a eso para casi cualquier cosa que dependa de una arquitectura basada en mensajes.

Con todo esto dicho, un estándar es tan bueno como aquellos que lo aceptan. Con ese fin, AsyncAPI tiene varios nombres importantes que respaldan su uso e implementación. AsyncAPI es utilizado por gigantes de la industria como Salesforce, MuleSoft, Slack y Tibco con gran efecto para impulsar la documentación de sus sistemas basados ​​en mensajes.

Con esto en mente, ¿qué hace AsyncAPI específicamente para resolver los problemas que exigen estándares? ¿Y por qué tantos grandes nombres utilizan AsyncAPI como parte de su solución?

AsyncAPI es un mecanismo de contrato

“Todos ustedes han sentido el dolor de no tener un contrato para todos sus mensajes en su sistema. Sabes que tenemos RAML, tenemos OpenAPI, tenemos muchos lenguajes de especificación para nuestros contratos de API, pero a menudo nos olvidamos del contrato de la API de mensajería. Esto es especialmente importante porque tendemos a enviar mensajes a un intermediario del sistema ".

AsyncAPI funciona con dos suposiciones: que los mensajes impulsan la mayoría de las interacciones API en su núcleo y que estos mensajes son acciones o eventos. En esencia, AsyncAPI cree que todo se puede representar como un sistema de mensajes, con un encabezado y una carga útil como opcionales y no obligatorios. En esta vista de la comunicación API, AsyncAPI busca habilitar la definición de API utilizando definiciones basadas en canales independientes del protocolo.

Al definir una relación contractual muy específica entre los elementos de la API, los desarrolladores pueden controlar y gestionar con mayor precisión el flujo de estos mensajes y su salida resultante. Dado que estos mensajes generalmente se envían a un corredor, tener un contrato comúnmente definido y aceptado permite un sistema de control granular mucho más alto, lo que finalmente da como resultado un sistema más comprensible, efectivo y eficiente en general.

Lea también: Las 5 principales tendencias de diseño de API de 2019

AsyncAPI es un protocolo agnóstico

“[AsyncAPI no] aplica ningún protocolo en particular, pero ofrecemos mecanismos para definir cuál usa su API. Eso se debe a los muchos enfoques diferentes en el mundo de la mensajería sobre cómo funcionan las cosas ".

Al cambiar el enfoque de las interacciones en la API de un componente a otro y, en su lugar, representarlo como un sistema simple basado en mensajes, AsyncAPI puede describir las API de una manera más eliminada. Estas descripciones están en JSON o YAML y describen la estructura fundamental del mensaje, en lugar de las interacciones de los componentes; en consecuencia, AsyncAPI es independiente del protocolo.

El agnosticismo de protocolo es un elemento muy importante para este tipo de solución debido a la propia naturaleza del enfoque basado en mensajes. Existen muchas soluciones que ofrecen el mismo tipo de metodologías de documentación en una variedad de API, pero estas a menudo están bloqueadas en un lenguaje o formato propietario. Si bien esto no es un problema cuando el código base ya se adhiere a estas reglas, es una restricción que es más un obstáculo que un beneficio.

Al permanecer independiente del protocolo, AsyncAPI puede evitar un estándar unificado sin tener que desarrollar una amplia variedad de integraciones y sistemas de portabilidad; en gran medida, debería funcionar de inmediato.

Relacionado: 7 protocolos buenos para documentar con AsyncAPI

AsyncAPI es extensible

Aunque no es tan destacado como otros elementos de este documento, el hecho de que AsyncAPI sea de código abierto es muy importante para el éxito de dicho estándar. Al ser de código abierto, AsyncAPI tiene dos beneficios importantes que simplemente no serían posibles en un sistema de código cerrado.

En primer lugar, una AsyncAPI de código abierto es auditable. El código se puede probar, revisar y revisar, lo que significa que cualquier inquietud sobre cómo funciona el sistema puede identificarse y solucionarse con relativa facilidad y a un costo promedio más bajo.

En segundo lugar, ser de código abierto significa que AsyncAPI ofrece una plataforma estándar a partir de la cual construir. Si un proveedor encuentra que AsyncAPI hace casi todo, quiere que lo haga, pero no del todo, el resultado es diferente entre las implementaciones de código abierto y cerrado: en un código cerrado, el proveedor debe esperar una integración personalizada de empresa a empresa. o simplemente aceptar que no tienen suerte; en un entorno de código abierto, el sistema central se puede personalizar y cambiar, siempre que las licencias coincidan, para que sea precisamente lo que el proveedor necesita.

AsyncAPI está diseñado para máxima legibilidad

Anteriormente, se discutieron en detalle las diferencias (e importancia) de los modelos de legibilidad. La legibilidad de la máquina ofrece una excelente portabilidad y extensibilidad. La legibilidad humana permite un uso e integración más fáciles en tiempo real. Adoptar uno sobre el otro es una cuestión de necesidad y conveniencia - con AsyncAPI; sin embargo, no es necesario realizar esta elección, ya que AsyncAPI está diseñado para admitir ambos. Las API se pueden describir utilizando JSON o YAML, y las GUI se pueden integrar con la experiencia AsyncAPI para una máxima usabilidad.

Tener ambas opciones para el proveedor no solo tiene sentido comercial, también tiene sentido de diseño: la persona que solicita los datos tomará la decisión final, y permitirle tomar esa decisión de forma independiente sin limitaciones dará como resultado una mejor experiencia.

Cómo se ve AsyncAPI

Si bien hemos discutido la implementación de nivel superior de AsyncAPI, también ayuda incluir algún código real para el aspecto de AsyncAPI como una especie de barómetro para los proveedores que buscan una nueva solución. Con ese fin, se proporciona lo siguiente como una guía aproximada de cómo funciona AsyncAPI y cómo se ve. Este contenido está tomado en gran parte de la primera pieza sobre este tema en las API nórdicas, Tooling Review: AsyncAPI .

AsyncAPI se ocupa principalmente de las representaciones contractuales del sistema de mensajería API. En consecuencia, lo primero que hace es definir un objeto de información. El objeto de información es el método principal mediante el cual la API establece su título, descripción, etc. La declaración del objeto de información tiene el siguiente aspecto:

{
  "asyncapi": "2.0.0",
  "info": {
    "title": "AsyncAPI Sample App",
    "description": "This is a sample server.",
    "termsOfService": "http://asyncapi.org/terms/",
    "contact": {
      "name": "API Support",
      "url": "http://www.asyncapi.org/support",
      "email": "support@asyncapi.org"
    },
    "license": {


      "name": "Apache 2.0",
      "url": "http://www.apache.org/licenses/LICENSE-2.0.html"
    },
    "version": "1.0.1"
  }

El siguiente paso en este proceso es la creación del objeto Servidores. Este objeto define las URL del servidor y es la definición principal y el método de enrutamiento utilizado para manejar los mensajes de la API. Tiene el siguiente aspecto:

"servers": {
"development": { "url": "development.gigantic-server.com", "description": "Development server", "protocol": "mqtt" }, "staging": { "url": "staging.gigantic-server.com", "description": "Staging server", "protocol": "secure-mqtt" }, "production": { "url": "api.gigantic-server.com", "description": "Production server", "protocol": "secure-mqtt" } }

Una vez que hemos definido nuestro objeto Servidores, necesitamos establecer el elemento Canales. En el lenguaje de AsyncAPI, el canal es la definición de nivel superior mediante la cual se definen todos los mensajes; se pueden considerar aproximadamente análogos a las rutas de URL de la API HTTP, y esta definición se utiliza para gobernar la transferencia de mensajes de acuerdo con el propósito y el contenido. Esta definición tiene el siguiente aspecto:

"channels": {
"user/signedup": { "subscribe": { "message": { "$ref": "#/components/messages/userSignedUp" } } } }

Ahora que tenemos las bases establecidas, podemos definir los Componentes. Los componentes son objetos reutilizables cuyo único propósito es definir y limitar mensajes; este es el principal mecanismo de control empleado por AsyncAPI. Tiene el siguiente aspecto:

"components": {
"schemas": { "email": { "type": "string", "format": "email" }, "sentAt": { "type": "string", "format": "datetime" }, "address": { "type": "object", "properties": { "street": { "type": "string" }, "postalCode": { "type": "string" }, "city": { "type": "string" }, "region": { "type": "string" }, "country": { "type": "string" } } } }, "messages": { "userSignedUp": { "summary": "Action to sign a user up.", "description": "Multiline description of what this action does.\nHere you have another line.\n", "tags": [ { "name": "user" }, { "name": "signup" } ], "bindings": { "mqtt": { "cleanSession": false, "clientId": "myApp" } }, "headers": { "type": "object", "properties": { "myAppHeader": { "type": "string" } } }, "payload": { "type": "object", "properties": { "username": { "type": "string" }, "email": { "$ref": "#/components/schemas/email" }, "address": { "$ref": "#/components/schemas/address" }, "sentAt": { "$ref": "#/components/schemas/sentAt" } } } } } } }

Conclusión

AsyncAPI no es una fórmula mágica: siempre habrá estándares en competencia y soluciones adicionales específicas para cada caso. Dicho esto, AsyncAPI es muy poderoso en lo que hace y es una muy buena solución para cualquier caso de uso basado en mensajes. Con grandes nombres de la industria que lo apoyan directamente, es difícil argumentar en contra de la implementación sobre la base de la usabilidad; además, su extensibilidad es de clase mundial, con su base de código de fuente abierta que ofrece excelentes oportunidades para soluciones personalizadas además de metodologías estandarizadas. .

¿Qué opinas sobre AsyncAPI y su búsqueda para convertirse en un estándar de la industria? ¡Háganos saber a continuación!

Publicar un comentario

0 Comentarios