Apicurio-studio: Kann den AsyncAPI-Standard im Editor unterstützen

Ich würde gerne einen visuellen Editor von Apicurio für AsyncAPI sehen. Im Moment hat dieses Projekt nicht die Engineering-Bandbreite für einen solchen Aufwand. :(

@EricWittmann danke für die Antwort. Ich werde versuchen, etwas Zeit für die Arbeit an diesem Feature zu finden, wenn es nicht so schwierig ist...

Nun, ich denke, das Hinzufügen von Unterstützung für AsyncAPI ist eine riesige Menge an Arbeit. Die erste Aufgabe wäre wahrscheinlich, eine Parser-/Modellschicht dafür zu implementieren. Für OAI habe ich das hier gemacht:

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

Das ist wahrscheinlich ein guter Anfang - vielleicht ein neues Repository wie asyncapi-ts-core .

Wenn du Lust auf sowas hast, wäre das toll! Ich müsste mir überlegen, wie ich am besten Asyncapi-Unterstützung in den Rest von Apicurio integrieren kann. Auf den verschiedenen UI-Seiten gibt es eine Reihe von Überlegungen.

Für was es wert ist, nimmt AsyncAPI etwas zusätzlichen Dampf auf. Daher klettert die Unterstützung in Apicurio auf der Prioritätenliste nach oben. :) NOCH keine ETA oder ähnliches - aber hoffentlich können wir in diesem Bereich Fortschritte machen.

Schön , diese Nachricht zu hören,

FWIW, wir haben jetzt einen Parser für AsyncAPI 2.0.0 . Wir haben über die Migration zu Typescript gesprochen. Es wäre toll, eine Liste der Aufgaben zu haben, die getan werden müssen, um AsyncAPI in Apicurio zu haben. Vielleicht können wir helfen :)

Das ist interessant, @fmvilas - danke für den https://github.com/Apicurio/apicurio-data-models

Diese Bibliothek ist in Java geschrieben und in Typescript transpiliert, sodass wir sie sowohl in unserem Back-End als auch direkt in unserer Benutzeroberfläche verwenden können. Es verfügt auch über verschiedene Funktionen wie vollständige Besucherunterstützung, eine einfache operative Transformationsmaschine usw.

Kommen wir zum interessanteren Teil Ihres Kommentars - Aufgaben, die erledigt werden müssen, um AsyncAPI in Apicurio zu haben. :) :) Ich denke, das große Ding im Moment ist wahrscheinlich die Editor-Unterstützung. Letztendlich hätte ich gerne eine Funktionsgleichheit mit unserem visuellen OpenAPI-Editor (der Validierung und gleichzeitige Bearbeitung unterstützt). Ein netter (vielleicht vorübergehender) Beitrag wäre jedoch kurzfristig meiner Meinung nach, den bestehenden textbasierten AsyncAPI-Editor in Apicurio zu integrieren. Das wäre sehr cool und würde viel bringen. Ich könnte mir eine Zukunft vorstellen, in der sowohl der textbasierte Editor als auch der visuelle Editor unterstützte Optionen sind. Ich hatte tatsächlich einen Community-Benutzer, der danach gefragt hat – ihre leitenden Entwickler mochten den visuellen Editor nicht und wollten stattdessen einen Texteditor. Stelle dir das vor.

Anders als der Redakteur müsste ich über die Liste der Aufgaben nachdenken. Aber alles andere wäre zusätzlich zum Editor inkrementell (zB Projektgenerierung).

Kommen wir zum interessanteren Teil Ihres Kommentars - Aufgaben, die erledigt werden müssen, um AsyncAPI in Apicurio zu haben. :) :)

Ich höre dich :)

Nun, wie gesagt, fangen wir mit etwas Leichtem/Einfachem an. Ich werde Sie wissen lassen, sobald wir etwas Bandbreite für die Zusammenarbeit haben. Danke!

Eine Zusammenarbeit wäre sicher toll. Wenn Sie in der Zwischenzeit eine Dokumentation zum Einbetten des AsyncAPI-Editors in andere Anwendungen haben, könnte ich wahrscheinlich ziemlich schnell etwas Interessantes als POC herausholen.

Ich beziehe mich auf den Editor, der hier auf dem Spielplatz zu finden ist: https://playground.asyncapi.io/

Ich habe mir das noch nicht angesehen - bin mir also nicht sicher, ob es für die einfache Nutzung in anderen Anwendungen entwickelt wurde, aber wenn ja, dann ist es hoffentlich nicht schwer zu importieren und zu verwenden. Das würde viel dazu beitragen, die (zumindest anfängliche) AsyncAPI-Unterstützung in Apicurio Studio zu beanspruchen.

Hallo @EricWittmann ,

Ich verbringe heute einige Zeit damit, zu untersuchen, was das Hinzufügen eines grafischen Editors für AsyncAPI kosten würde, und komme in letzter Zeit zu einem Ergebnis. Siehe Screenshot unten - Ich habe dieselbe Struktur wie OpenAPI neu erstellt und den Code-Editor hinzugefügt, den wir bereits haben, sodass wir bereits eine Funktionsparität gegenüber dem heutigen haben. Ich habe mit dem AsyncAPI-Beispiel begonnen, das ich zuvor hinzugefügt habe.

Ein paar Gedanken und Fragen, die ich teilen möchte:

• 1. auf der Implementierungsseite: Es war bereits eine neue Editor-Komponente vorhanden und ich verfolge dies, indem ich vorhandene Komponenten in ihr AsyncApi* Gegenstück dupliziere. Meistens einfach OasDocument durch AaiDocument ersetzen, das ist nicht so elegant ... Ich habe jedoch nur an der Oberfläche gekratzt und es wird wichtigere Unterschiede zwischen den 2 Spezifikationen geben ... Würden Sie es vorziehen, dies beizubehalten und zwei unabhängige Sätze von Komponenten zu verwenden oder zu versuchen, sich zu vereinheitlichen, selbst wenn der Code viele if document.isOpenApi() oder if document.isAsyncApi() enthält? Was denkst du ?

• 2. auf den Prozess. Wie Sie bereits sagten, kann es ein großer Aufwand sein ... Technisch nicht schwierig, aber langwierig und akribisch ... Ich glaube also nicht, dass ich die Geduld haben werde, noch es machbar ist, die gesamten Spec-Editoren zu implementieren, bevor Sie etwas festlegen. Ich würde das eher als eine iterative Aufgabe sehen, bei der ich einige Teile beginnend mit hohen Prioritäten füllen könnte ( Channels , DataTypes , Messages , Examples ;- )) und dann niedrigere Prioritäten ( Servers , Traits und so weiter...). Was denkst du ? Wäre es in Ordnung, die Implementierung auf viele Pull Requests aufzuteilen?

Ich würde wirklich gerne helfen, da Sie vielleicht gesehen haben, dass Microcks jetzt AsyncAPI-Mocking unterstützt (und in ein paar Wochen getestet wird). Es könnte also ein Wendepunkt sein, wenn Apicurio dies unterstützt und es ermöglicht, die wichtigsten Stile moderner API-Spezifikationen abzudecken.

cc @fmvilas ;-)

Zunächst einmal herzlichen Glückwunsch zum Hinzufügen der AsyncAPI-Unterstützung in Microcks! Ich habe gesehen, dass das vor kurzem hinzugefügt wurde.

Ich habe ein paar Gedanken dazu. Erstens denke ich, dass es sinnvoll sein könnte zu versuchen, den AsyncAPI Playground-Editor in Apicurio Studio einzubetten, wenn dies technisch "einfach" ist. :) Das wäre ein schneller Gewinn und würde uns eine vernünftige "Beta"-Unterstützung für die Bearbeitung von AsyncAPI-Dokumenten in Apicurio Studio geben.

Danach konnten wir uns darauf konzentrieren, einen visuellen Editor zu erstellen.

(1) Was Ihre Frage zur Implementierung angeht - ich denke, die Komponenten zu duplizieren und sie an die AsyncAPI anzupassen, ist kurzfristig der richtige Ansatz. Der Grund dafür ist, dass es einfach genug ist, später umzugestalten, um Komponenten zwischen den beiden Editoren zu teilen, aber mehr als das ist, dass wir irgendwann die gesamte Studio-Benutzeroberfläche in React neu implementieren werden. Alle großen Anstrengungen, die wir bei der aktuellen Angular-Implementierung unternehmen, wären also vergeblich. Es ist besser, schnell etwas zu tun, da es später sowieso neu gemacht werden muss.

(2) Ich stimme zu, dass der Aufwand technisch nicht schwierig, aber langwierig und akribisch ist. :) Ich denke, es ist sinnvoll, die Implementierung in mehrere PRs aufzuteilen - hoffentlich können wir die Arbeit auch auf mehrere Mitwirkende aufteilen.

@fmvilas Ist der Editor im Open Source AsyncAPI Playground zu finden (ich gehe davon aus) und kann er auch problemlos in andere Tools wie Apicurio Studio integriert werden?

(Wenn ja, wären Hinweise zur Anleitungsdokumentation großartig)

Danke @EricWittmann !

Ich habe zuerst einen kurzen Blick auf den AsyncAPI-Spielplatz geworfen, aber er scheint serverseitige Komponenten in NodeJS zu haben. Da dachte ich mir, dass die Integration nicht so einfach ist ... deshalb erkunde ich den Editor-Weg ;-)

Ende der Woche sollte ich noch etwas Zeit damit verbringen können... Wenn es für dich in Ordnung ist, versuche ich Anfang nächster Woche eine erste PR einzureichen. Es sollte möglich sein, die Hauptinformationen editierbar zu haben ( Version , Contact , License und Tags ) sowie eine schreibgeschützte Vorschau der Channels in der linken Spalte.

Es ist Open Source, Sie finden es hier . Wir arbeiten jedoch an einem viel besseren mit automatischer Vervollständigung, Fehlern, die im Editor selbst durch "Unterstreichen" der falschen Zeilen und Spalten usw. gemeldet werden. Es ist tatsächlich dasjenige, das auf AsyncAPI Hub zu sehen ist und irgendwann den Playground ersetzen wird. Dieser ist noch nicht Open Source, wird aber sehr bald, sicher vor Ende des Jahres, und in React mit dem Monaco-Editor (dem Editor, der VS Code antreibt) erstellt werden.

Aber da Sie Angular bei Apicurio Studio verwenden, bin ich mir nicht sicher, ob es hilfreich sein wird. Ich habe gehört, dass es möglich ist, React und Angular zu kombinieren, aber ehrlich gesagt nie versucht.

Danke @fmvilas - wir werden letztendlich auch zu React konvertieren (das ist in Arbeit). Benötigt der neue AsyncAPI-Editor irgendwelche Serverkomponenten oder handelt es sich um rein clientseitiges React? Und soll es in andere Projekte eingebettet werden?

Wir hätten nie gedacht, dass andere daran interessiert sein könnten, es einzubetten, aber es sollte einfach sein, da es bereits eine isolierte Komponente ist, also können wir es leicht einbetten. Die Komponente ist rein clientseitig React, da Monaco kein serverseitiges Rendering unterstützt.

Erste PR für das Bootstrapping des Editors auf dem Weg! Siehe #1280

Und hier ist noch einer bei #1285 ;-)

Sehr bald sollten wir die AsyncAPI-Unterstützung standardmäßig aktivieren (die Funktion ist meiner Meinung nach derzeit standardmäßig deaktiviert).

Hallo @EricWittmann und alle!

Hier ist ein weiterer mit: Operation, Message, OperationTrait und MessageTrait-Unterstützung. Siehe #1313 ;-)

Alle Details jedes Konzepts sind noch nicht vollständig in grafischer Form implementiert, aber das Framework ist vorhanden.

Hallo zusammen!

Habe dieses Wochenende etwas Zeit für einige neue Verbesserungen gefunden: Hier ist ein weiterer PR #1382.

Wir können jetzt eine neue Operation erstellen, den Payload- und Header-Typ festlegen sowie Beispiele bereitstellen (nützlich, da wir AsyncAPI direkt mit dem Microcks-Connector nachahmen können 😉 )

@EricWittmann wie aktiviert man es?

Für den Container apicurio-studio-ui müssen Sie die Umgebungsvariable APICURIO_UI_FEATURE_ASYNCAPI auf "true" (als String, nicht boolean), @alizard0 setzen .