Apicurio-studio: Capaz de admitir el estándar AsyncAPI en el editor

Creado en 25 sept. 2018  ·  23Comentarios  ·  Fuente: Apicurio/apicurio-studio

Como AsyncAPI tiene su propio editor AsyncAPI , sería mejor unir este formato y soporte visual (el editor AsyncAPI no tiene esta opción y solo descripción yaml -> soportes visuales).
@EricWittmann ¿qué opinas al respecto? ¿O esta es una idea loca?

proposal

Comentario más útil

Muy pronto deberíamos habilitar la compatibilidad con AsyncAPI de forma predeterminada (creo que la función está actualmente desactivada de forma predeterminada).

Todos 23 comentarios

Me encantaría ver un editor visual de Apicurio para AsyncAPI. En este momento, este proyecto no tiene el ancho de banda de ingeniería para tal esfuerzo. :(

@EricWittmann gracias por la respuesta. Intentaré encontrar algo de tiempo para trabajar en esta función si no va a ser tan difícil ...

Bueno, creo que agregar soporte para AsyncAPI es una gran cantidad de trabajo. La primera tarea probablemente sería implementar una capa de analizador / modelo para él. Para OAI lo he hecho aquí:

https://github.com/apicurio/oai-ts-core

Entonces, ese es probablemente un buen lugar para comenzar, tal vez un nuevo repositorio como asyncapi-ts-core .

Si estás preparado para ese tipo de cosas, ¡sería genial! Necesitaría comenzar a pensar en la mejor manera de obtener soporte de asyncapi en el resto de Apicurio. Hay una serie de consideraciones en las distintas páginas de la interfaz de usuario.

Por lo que vale, AsyncAPI está comenzando a ganar fuerza adicional. Entonces, brindarle soporte en Apicurio está subiendo en la lista de prioridades. :) Sin ETA ni nada por el estilo AÚN - pero espero que podamos empezar a hacer algunos progresos en esta área.

Es bueno escuchar esta noticia, @EricWittmann , gracias. Me gustaría participar, si tengo suficiente tiempo.

FWIW, ahora tenemos un analizador para AsyncAPI 2.0.0 . Hemos estado discutiendo sobre la migración a Typecript. Sería genial tener una lista de tareas de lo que se debe hacer para tener AsyncAPI en Apicurio. Es posible que podamos ayudar :)

Eso es interesante, @fmvilas , gracias por el puntero. De hecho, hemos construido nuestra propia implementación de modelo de datos unificados para AsyncAPI y OpenAPI aquí: https://github.com/Apicurio/apicurio-data-models

Esa biblioteca está escrita en Java y se transpila a TypeScript para que podamos usarla tanto en nuestro back-end como directamente en nuestra interfaz de usuario. También tiene varias características como soporte completo para visitantes, un motor de transformación operativa simple, etc.

Pasemos a la parte más interesante de su comentario: tareas que deben realizarse para tener AsyncAPI en Apicurio. :) :) Creo que lo más importante en este momento es probablemente la compatibilidad con el editor. En última instancia, me gustaría tener paridad de funciones con nuestro editor visual OpenAPI (que incluye validación y soporte de edición concurrente). Sin embargo, creo que una buena contribución (quizás temporal) a corto plazo sería integrar el editor AsyncAPI existente basado en texto en Apicurio. Eso sería genial y sería de gran ayuda. Podría ver un futuro en el que el editor basado en texto y el editor visual sean opciones compatibles. De hecho, un usuario de la comunidad me pidió eso: a sus desarrolladores principales no les gustó el editor visual y, en cambio, querían un editor de texto. Imagínate.

Aparte del editor, tendría que pensar en la lista de tareas. Pero todo lo demás sería incremental en la parte superior del editor (por ejemplo, generación de proyectos).

Pasemos a la parte más interesante de su comentario: tareas que deben realizarse para tener AsyncAPI en Apicurio. :) :)

Te escucho :)

Bueno, como dijiste, comencemos con algo fácil / más fácil. Te lo haré saber tan pronto como tengamos algo de ancho de banda para colaborar. ¡Gracias!

La colaboración sería increíble, seguro. Mientras tanto, si tiene alguna documentación sobre cómo incrustar el editor AsyncAPI en otras aplicaciones, probablemente podría eliminar algo interesante como un POC con bastante rapidez.

Me refiero al editor que se encuentra en el patio de juegos aquí: https://playground.asyncapi.io/

No lo he investigado todavía, por lo que no estoy seguro de si se ha creado para que se pueda aprovechar fácilmente en otras aplicaciones, pero si es así, es de esperar que no sea difícil de importar y usar. Eso sería de gran ayuda para reclamar el soporte AsyncAPI (al menos inicial) dentro de Apicurio Studio.

Hola @EricWittmann ,

Pasé algún tiempo investigando hoy cuál sería el costo de agregar un editor gráfico para AsyncAPI y últimamente llegué al comienzo de un resultado. Vea la captura de pantalla a continuación: recreé la misma estructura que OpenAPI y agregué el editor de código que ya tenemos, por lo que ya tenemos paridad de funciones frente a lo que tenemos hoy. Comencé desde el ejemplo de AsyncAPI que agregué anteriormente.

asyncapi-editor-01
asyncapi-editor-02

Algunos pensamientos y preguntas que me gustaría compartir:

  • Primero en el lado de la implementación: el nuevo componente del editor ya estaba presente y sigo esto duplicando los componentes existentes en su contraparte AsyncApi* . La mayoría de las veces simplemente reemplazando OasDocument por AaiDocument , eso no es tan elegante ... Sin embargo, acabo de arañar la superficie y habrá diferencias más importantes entre las 2 especificaciones ... ¿Preferiría mantenerse de esta manera y tener 2 conjuntos independientes de componentes o intentar mutualizar incluso si habrá una gran cantidad de if document.isOpenApi() o if document.isAsyncApi() largo del código? Qué piensas ?

  • 2º en el proceso. Como dijiste antes, puede ser un gran esfuerzo ... No técnicamente difícil pero largo y meticuloso ... Así que no creo que tenga la paciencia ni sea factible implementar todos los editores de especificaciones antes de comprometer nada. Prefiero ver eso como una tarea iterativa en la que podría completar algunas piezas comenzando con prioridades altas ( Channels , DataTypes , Messages , Examples ; - )) luego ir a prioridades más bajas ( Servers , Traits y así sucesivamente ...). Qué piensas ? ¿Estaría bien dividir la implementación en muchas solicitudes de extracción?

Realmente estaría feliz de ayudar, ya que es posible que haya visto que Microcks ahora es compatible con las burlas de AsyncAPI (y las pruebas en unas pocas semanas). Por lo tanto, podría ser un cambio de juego contar con el soporte de Apicurio y permitir cubrir los principales estilos de especificaciones de API modernas.

cc @fmvilas ;-)

En primer lugar, ¡felicidades por la incorporación de la compatibilidad con AsyncAPI en Microcks! Vi que se agregó recientemente.

Tengo un par de pensamientos sobre esto. En primer lugar, creo que podría tener sentido intentar integrar el editor AsyncAPI Playground en Apicurio Studio si es técnicamente "fácil". :) Eso sería una victoria rápida y nos daría un soporte "beta" razonable para editar documentos AsyncAPI en Apicurio Studio.

Después de eso, podríamos concentrarnos en crear un editor visual.

(1) En cuanto a su pregunta sobre la implementación, creo que duplicar los componentes y modificarlos para que se ajusten a AsyncAPI es el enfoque correcto a corto plazo. La razón es que es bastante fácil refactorizar más tarde para compartir componentes entre los dos editores, pero más que eso es que volveremos a implementar toda la interfaz de usuario de Studio en React en algún momento. Por lo tanto, cualquier esfuerzo importante que hagamos en la implementación actual de Angular sería en vano. Es mejor hacer algo rápido, ya que de todos modos habrá que rehacerlo más tarde.

(2) Estoy de acuerdo en que el esfuerzo no es técnicamente difícil, pero es largo y meticuloso. :) Creo que tiene sentido que la implementación se divida en varios RP; con suerte, también podemos dividir el trabajo entre varios colaboradores.

@fmvilas ¿El editor se encuentra en el código abierto AsyncAPI Playground (supongo que sí) y también se puede integrar fácilmente en otras herramientas como Apicurio Studio?

(en caso afirmativo, cualquier sugerencia a la documentación de cómo sería increíble)

¡Gracias @EricWittmann !

Primero eché un vistazo rápido al patio de recreo de AsyncAPI, pero parece tener componentes del lado del servidor en NodeJS. Entonces estaba pensando que la integración no sería tan fácil ... por eso exploro la forma del editor ;-)

Debería poder dedicarle más tiempo al final de la semana ... Si está bien para usted, intentaré enviar un primer PR a principios de la próxima semana. Debería ser posible editar la información principal ( Version , Contact , License y Tags ), así como una vista previa de solo lectura de Channels en la columna del lado izquierdo.

Es de código abierto, puedes encontrarlo aquí . Sin embargo, estamos trabajando en uno mucho mejor con autocompletado, errores reportados en el propio editor al "subrayar" las líneas y columnas incorrectas, etc. En realidad, es el que se ve en AsyncAPI Hub , que eventualmente reemplazará a Playground. Este aún no es de código abierto, pero lo será muy pronto, antes de fin de año con seguridad, y está hecho en React usando el editor de Mónaco (el editor que impulsa VS Code).

Pero dado que está usando Angular en Apicurio Studio, no estoy seguro de que sea útil. Escuché que es posible combinar React y Angular pero, sinceramente, nunca lo intenté.

Gracias @fmvilas . En última instancia, también nos convertiremos a React (eso está en progreso). ¿El nuevo editor AsyncAPI requiere algún componente de servidor o es React puramente del lado del cliente? ¿Y está destinado a integrarse en otros proyectos?

Nunca pensamos que otros podrían estar interesados ​​en incrustarlo, pero debería ser fácil de hacer porque ya es un componente aislado, así que sí, podemos hacerlo fácilmente incrustable. El componente es React puramente del lado del cliente porque Monaco no admite la representación del lado del servidor.

¡Primer PR para iniciar el editor en su camino! Ver # 1280

Y aquí hay otro en el # 1285 ;-)

Muy pronto deberíamos habilitar la compatibilidad con AsyncAPI de forma predeterminada (creo que la función está actualmente desactivada de forma predeterminada).

¡Hola @EricWittmann y todos!

Aquí hay otro que trae: soporte Operation, Message, OperationTrait y MessageTrait. Ver # 1313 ;-)

Todos los detalles de cada concepto aún no están completamente implementados como forma gráfica, pero el marco está ahí.

¡Hola a todos!

Encontré algo de tiempo este fin de semana para algunas mejoras nuevas: aquí hay otro PR # 1382.

Ahora podemos crear una nueva operación, establecer el tipo de carga útil y encabezados, así como proporcionar ejemplos (útil ahora que podemos simular directamente AsyncAPI con el conector Microcks 😉)

@EricWittmann ¿cómo se habilita?

Para el contenedor apicurio-studio-ui, debe establecer la variable de entorno APICURIO_UI_FEATURE_ASYNCAPI en "true" (como cadena, no booleana), @ alizard0 .

¿Fue útil esta página
0 / 5 - 0 calificaciones