Apicurio-studio: Capable de prendre en charge la norme AsyncAPI dans l'éditeur

J'aimerais voir un éditeur visuel Apicurio pour AsyncAPI. À l'heure actuelle, ce projet n'a pas la bande passante d'ingénierie pour un tel effort. :(

@EricWittmann merci pour la réponse. Je vais essayer de trouver du temps pour travailler sur cette fonctionnalité si ce ne sera pas si difficile...

Eh bien, je pense que l'ajout de la prise en charge d'AsyncAPI est une énorme quantité de travail. La première tâche serait probablement d'implémenter une couche d'analyseur/modèle pour cela. Pour OAI, je l'ai fait ici :

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

C'est donc probablement un bon point de départ - peut-être un nouveau référentiel comme asyncapi-ts-core .

Si vous êtes partant pour ce genre de chose, ce serait génial ! Je devrais commencer à réfléchir à la meilleure façon d'obtenir le support asyncapi dans le reste d'Apicurio. Il y a un certain nombre de considérations à travers les différentes pages de l'interface utilisateur.

Pour ce que ça vaut, AsyncAPI commence à prendre de l'ampleur. Donc, fournir un support pour cela dans Apicurio grimpe dans la liste des priorités. :) Pas d'ETA ou quelque chose comme ça ENCORE - mais j'espère que nous pourrons commencer à faire des progrès dans ce domaine.

C'est bon d'entendre cette nouvelle, @EricWittmann , merci. J'aimerais participer, si je trouve assez de temps.

FWIW, nous avons maintenant un analyseur pour AsyncAPI 2.0.0 . Nous avons discuté de la migration vers Typescript. Ce serait formidable d'avoir une liste de tâches de ce qui doit être fait pour avoir AsyncAPI dans Apicurio. Nous pourrions être en mesure d'aider :)

C'est intéressant, @fmvilas - merci pour le pointeur. Nous avons en fait construit notre propre implémentation de modèle de données unifié pour AsyncAPI et OpenAPI ici : https://github.com/Apicurio/apicurio-data-models

Cette bibliothèque est écrite en Java et est transpilée en Typescript afin que nous puissions l'utiliser à la fois dans notre back-end et également directement dans notre interface utilisateur. Il dispose également de diverses fonctionnalités comme une prise en charge complète des visiteurs, un simple moteur de transformation opérationnelle, etc...

Passons à la partie la plus intéressante de votre commentaire - les tâches qui doivent être effectuées pour avoir AsyncAPI dans Apicurio. :) :) Je pense que la grande chose en ce moment est probablement le support de l'éditeur. En fin de compte, j'aimerais avoir la parité des fonctionnalités avec notre éditeur visuel OpenAPI (qui inclut la validation et la prise en charge de l'édition simultanée). Cependant, je pense qu'une contribution intéressante (peut-être temporaire) à court terme serait d'intégrer l'éditeur AsyncAPI basé sur du texte existant dans Apicurio. Ce serait très cool et irait un long chemin. Je pouvais voir un avenir où l'éditeur de texte et l'éditeur visuel seraient tous deux des options prises en charge. En fait, un utilisateur de la communauté m'a demandé cela - leurs développeurs seniors n'aimaient pas l'éditeur visuel et voulaient plutôt un éditeur de texte. Allez comprendre.

À part l'éditeur, il faudrait que je réfléchisse à la liste des tâches. Mais tout le reste serait incrémental au-dessus de l'éditeur (par exemple, la génération de projet).

Passons à la partie la plus intéressante de votre commentaire - les tâches qui doivent être effectuées pour avoir AsyncAPI dans Apicurio. :) :)

Je t'entends :)

Eh bien, comme vous l'avez dit, commençons par quelque chose de facile/plus facile. Je vous ferai savoir dès que nous aurons de la bande passante pour collaborer. Merci!

La collaboration serait géniale, c'est sûr. En attendant, si vous avez de la documentation sur la façon d'intégrer l'éditeur AsyncAPI dans d'autres applications, je pourrais probablement éliminer assez rapidement quelque chose d'intéressant en tant que POC.

Je fais référence à l'éditeur trouvé dans le terrain de jeu ici : https://playground.asyncapi.io/

Je n'ai pas encore examiné cela - je ne sais donc pas s'il a été conçu pour être facilement exploité dans d'autres applications, mais si tel est le cas, j'espère que ce n'est pas difficile à importer et à utiliser. Cela contribuerait grandement à revendiquer la prise en charge (au moins initiale) d'AsyncAPI au sein d'Apicurio Studio.

Salut @EricWittmann ,

Je passe du temps à étudier aujourd'hui quel serait le coût de l'ajout d'un éditeur graphique pour AsyncAPI et je suis arrivé au début d'un résultat ces derniers temps. Voir la capture d'écran ci-dessous - J'ai recréé la même structure qu'OpenAPI et ajouté l'éditeur de code que nous avons déjà, nous avons donc déjà la parité des fonctionnalités par rapport à ce que nous avons aujourd'hui. Je suis parti de l'exemple AsyncAPI que j'ai ajouté précédemment.

Quelques réflexions et questions que j'aimerais partager :

• 1er côté implémentation : le nouveau composant d'éditeur était déjà présent et je poursuis dans ce sens en dupliquant les composants existants dans leur équivalent AsyncApi* . La plupart du temps, il suffit de remplacer OasDocument par AaiDocument , ce n'est pas si élégant ... Cependant, je viens de gratter la surface et il y aura des différences plus importantes entre les 2 spécifications ... Préféreriez-vous garder cette voie et avoir 2 ensembles de composants indépendants ou essayer de mutualiser même s'il y aura beaucoup de if document.isOpenApi() ou if document.isAsyncApi() long du code ? Qu'en penses-tu ?

• 2e sur le processus. Comme vous l'avez dit précédemment, cela peut être un gros effort... Pas techniquement difficile mais long et méticuleux... Donc je ne pense pas que j'aurai la patience ni qu'il soit possible d'implémenter l'ensemble des éditeurs de spécifications avant de commettre quoi que ce soit. Je préfère voir cela comme une tâche itérative où je pourrais remplir certaines pièces en commençant par des priorités élevées ( Channels , DataTypes , Messages , Examples ;- )) puis passer aux priorités inférieures ( Servers , Traits et ainsi de suite...). Qu'en penses-tu ? Serait-il acceptable de diviser l'implémentation sur plusieurs Pull Requests ?

Je serais vraiment ravi de vous aider car vous avez peut-être vu que Microcks prend désormais en charge le mocking AsyncAPI (et les tests dans quelques semaines). Donc, cela pourrait changer la donne d'avoir Apicurio qui prend en charge cela et permet de couvrir les principaux styles de spécifications d'API modernes.

cc @fmvilas ;-)

Tout d'abord, félicitations pour l'ajout de la prise en charge d'AsyncAPI dans Microcks ! J'ai vu que cela avait été ajouté récemment.

J'ai quelques réflexions à ce sujet. Tout d'abord, je pense qu'il pourrait être judicieux d'essayer d'intégrer l'éditeur AsyncAPI Playground dans Apicurio Studio si cela est techniquement "facile". :) Ce serait une victoire rapide et nous donnerait une prise en charge "bêta" raisonnable pour l'édition de documents AsyncAPI dans Apicurio Studio.

Après cela, nous pourrions nous concentrer sur la création d'un éditeur visuel.

(1) Quant à votre question sur la mise en œuvre - je pense que la duplication des composants et leur modification pour s'adapter à AsyncAPI est la bonne approche à court terme. La raison en est qu'il est assez facile de refactoriser plus tard pour partager des composants entre les deux éditeurs, mais plus que cela, nous réimplémenterons l'intégralité de l'interface utilisateur de Studio dans React à un moment donné. Ainsi, tous les efforts importants que nous déployons dans la mise en œuvre actuelle d'Angular seraient vains. Mieux vaut faire quelque chose rapidement car il faudra de toute façon refaire plus tard.

(2) Je reconnais que l'effort n'est pas techniquement difficile mais qu'il est long et minutieux. :) Je pense qu'il est logique que la mise en œuvre soit divisée en plusieurs PR - j'espère que nous pourrons également répartir le travail entre plusieurs contributeurs.

@fmvilas L'éditeur se trouve-t-il dans l'open source AsyncAPI Playground (je suppose que oui) et peut également être facilement intégré à d'autres outils comme Apicurio Studio ?

(si oui, des pointeurs sur la documentation de howto seraient géniaux)

Merci @EricWittmann !

J'ai d'abord jeté un coup d'œil au terrain de jeu AsyncAPI, mais il semble avoir des composants côté serveur dans NodeJS. Alors je me disais que l'intégration ne serait pas si simple... c'est pourquoi j'explore la voie de l'éditeur ;-)

Je devrais pouvoir y consacrer un peu plus de temps d'ici la fin de la semaine... Si cela vous convient, j'essaierai de soumettre un premier PR en début de semaine prochaine. Il devrait être possible d'avoir les informations principales éditables ( Version , Contact , License et Tags ) ainsi qu'un aperçu en lecture seule du Channels dans la colonne de gauche.

C'est open source, vous pouvez le trouver ici . Cependant, nous travaillons sur un bien meilleur avec l'autocomplétion, les erreurs signalées dans l'éditeur lui-même en "soulignant" les mauvaises lignes et colonnes, etc. C'est en fait celui vu sur AsyncAPI Hub , qui finira par remplacer le Playground. Celui-ci n'est pas encore open source mais le sera très prochainement, avant la fin de l'année c'est certain, et c'est fait en React avec l' éditeur Monaco (l'éditeur alimentant VS Code).

Mais étant donné que vous utilisez Angular chez Apicurio Studio, je ne suis pas sûr que ce soit utile. J'ai entendu dire qu'il était possible de combiner React et Angular, mais honnêtement, je n'ai jamais essayé.

Merci @fmvilas - nous allons également nous convertir en React (c'est en cours). Le nouvel éditeur AsyncAPI nécessite-t-il des composants serveur ou s'agit-il uniquement de React côté client ? Et est-il destiné à être intégré à d'autres projets ?

Nous n'avons jamais pensé que d'autres pourraient être intéressés à l'intégrer, mais cela devrait être facile à faire car c'est déjà un composant isolé, alors oui, nous pouvons le rendre facilement intégrable. Le composant est purement React côté client car Monaco ne prend pas en charge le rendu côté serveur.

Premier PR pour démarrer l'éditeur en route ! Voir #1280

Et en voici un autre au #1285 ;-)

Très bientôt, nous devrions activer le support AsyncAPI par défaut (la fonctionnalité est actuellement désactivée par défaut je crois).

Salut @EricWittmann et à tous !

En voici un autre qui apporte : support Operation, Message, OperationTrait et MessageTrait. Voir #1313 ;-)

Tous les détails de chaque concept ne sont pas encore entièrement implémentés sous forme graphique mais le cadre est là.

Salut tout le monde!

J'ai trouvé du temps ce week-end pour de nouvelles améliorations : voici un autre PR #1382.

Nous pouvons maintenant créer une nouvelle opération, définir le type de charge utile et d'en-têtes ainsi que fournir des exemples (utile maintenant que nous pouvons directement simuler AsyncAPI avec le connecteur Microcks 😉 )

@EricWittmann comment l'activer ?

Pour le conteneur apicurio-studio-ui, vous devez définir la variable d'environnement APICURIO_UI_FEATURE_ASYNCAPI sur "true" (sous forme de chaîne, pas de booléen), @alizard0 .