Apicurio-studio: Возможность поддержки стандарта AsyncAPI в редакторе

Я бы хотел увидеть визуальный редактор Apicurio для AsyncAPI. Прямо сейчас у этого проекта нет инженерных возможностей для таких усилий. :(

@EricWittmann спасибо за ответ. Я постараюсь найти время для работы над этой функцией, если это не будет так сложно ...

Что ж, я думаю, что добавление поддержки AsyncAPI - это огромная работа. Первой задачей, вероятно, было бы реализовать для него слой парсера / модели. Для OAI я сделал это здесь:

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

Так что, вероятно, это хорошее место для начала - возможно, новый репозиторий, например asyncapi-ts-core .

Если вы готовы к подобным вещам, это будет здорово! Мне нужно было подумать о том, как лучше всего включить поддержку asyncapi в остальную часть Apicurio. Различные страницы пользовательского интерфейса учитывают ряд факторов.

Как бы то ни было, AsyncAPI начинает набирать обороты. Таким образом, обеспечение его поддержки в Apicurio поднимается вверх в списке приоритетов. :) Нет ETA или что-то в этом роде ЕЩЕ - но, надеюсь, мы сможем добиться некоторого прогресса в этой области.

Приятно слышать эту новость, @EricWittmann , спасибо. Хочу поучаствовать, если найду время.

FWIW, теперь у нас есть парсер для AsyncAPI 2.0.0 . Мы обсуждали переход на Typescript. Было бы здорово иметь список задач, которые необходимо сделать, чтобы иметь AsyncAPI в Apicurio. Возможно, мы сможем помочь :)

Вот интересно, @fmvilas - спасибо за указатель. Мы фактически создали нашу собственную реализацию унифицированной модели данных для AsyncAPI и OpenAPI здесь: https://github.com/Apicurio/apicurio-data-models

Эта библиотека написана на Java и перенесена в Typescript, поэтому мы можем использовать ее как в нашей серверной части, так и непосредственно в нашем пользовательском интерфейсе. Он также имеет различные функции, такие как полная поддержка посетителей, простой механизм оперативной трансформации и т. Д.

Переходим к более интересной части вашего комментария - задачам, которые необходимо выполнить, чтобы иметь AsyncAPI в Apicurio. :) :) Я думаю, что сейчас самое важное - это поддержка редактора. В конечном итоге я хотел бы иметь паритет функций с нашим визуальным редактором OpenAPI (который включает поддержку проверки и одновременного редактирования). Однако я думаю, что хорошим (возможно, временным) вкладом в краткосрочной перспективе будет интеграция существующего текстового редактора AsyncAPI в Apicurio. Это было бы очень круто и сыграло бы важную роль. Я мог видеть будущее, в котором текстовый редактор и визуальный редактор будут поддерживаться. У меня действительно был один пользователь сообщества, который просил об этом - их старшим разработчикам не нравился визуальный редактор, и вместо этого им нужен был текстовый редактор. Иди разберись.

Кроме редактора, мне пришлось бы подумать о списке задач. Но все остальное будет добавляться поверх редактора (например, создание проекта).

Переходим к более интересной части вашего комментария - задачам, которые необходимо выполнить, чтобы иметь AsyncAPI в Apicurio. :) :)

Я слышу тебя :)

Что ж, как вы сказали, давайте начнем с чего-нибудь более простого. Я сообщу вам, как только у нас появится пропускная способность для сотрудничества. Спасибо!

Безусловно, сотрудничество было бы потрясающим. Между тем, если у вас есть документация о том, как встраивать редактор AsyncAPI в другие приложения, я, вероятно, мог бы довольно быстро выделить что-нибудь интересное в качестве POC.

Я имею в виду редактор, который можно найти на детской площадке здесь: https://playground.asyncapi.io/

Я еще не изучал это - поэтому не уверен, был ли он создан для легкого использования в других приложениях, но если да, то, надеюсь, его несложно импортировать и использовать. Это будет иметь большое значение для утверждения (по крайней мере, начальной) поддержки AsyncAPI в Apicurio Studio.

Привет, @EricWittmann!

Сегодня я потратил некоторое время на то, чтобы исследовать, сколько будет стоить добавление графического редактора для AsyncAPI, и в последнее время пришел к началу результата. См. Снимок экрана ниже - я воссоздал ту же структуру, что и OpenAPI, и добавил редактор кода, который у нас уже есть, поэтому у нас уже есть паритет функций по сравнению с тем, что есть сегодня. Я начал с ранее добавленного примера AsyncAPI.

Несколько мыслей и вопросов, которыми я хотел бы поделиться:

• 1-й со стороны реализации: новый компонент редактора уже присутствовал, и я преследую его, дублируя существующие компоненты в их AsyncApi* аналог. В большинстве случаев просто замена OasDocument на AaiDocument , это не так уж элегантно ... Однако я только поцарапал поверхность, и между двумя спецификациями будут более важные различия ... Вы бы предпочли сохранить этот путь и иметь 2 независимых набора компонентов или попытаться объединить их, даже если в коде будет много if document.isOpenApi() или if document.isAsyncApi() ? Что вы думаете ?

• 2-й по ходу. Как вы сказали ранее, это может потребовать больших усилий ... Технически не сложно, но долго и кропотливо ... Так что я не думаю, что у меня хватит терпения, да и реализовать целые редакторы спецификаций перед тем, как что-то делать, невозможно. Я бы предпочел рассматривать это как итеративную задачу, в которой я мог бы заполнить некоторые части, начиная с высоких приоритетов ( Channels , DataTypes , Messages , Examples ; - )) затем переход к более низким приоритетам ( Servers , Traits и так далее ...). Что вы думаете ? Можно ли разделить реализацию на множество запросов на вытягивание?

Я был бы очень рад помочь, поскольку вы, возможно, видели, что Microcks теперь поддерживает имитацию AsyncAPI (и тестирование через несколько недель). Таким образом, это может изменить правила игры, если будет поддержка Apicurio, которая позволит охватить основные стили современных спецификаций API.

cc @fmvilas ;-)

Прежде всего - поздравляем с добавлением поддержки AsyncAPI в Microcks! Я видел, что это было добавлено недавно.

У меня есть пара мыслей по этому поводу. Во-первых, я думаю, что имеет смысл попробовать встроить редактор AsyncAPI Playground в Apicurio Studio, если это технически «легко». :) Это была бы быстрая победа и дала бы нам разумную «бета-поддержку» для редактирования документов AsyncAPI в Apicurio Studio.

После этого мы могли сосредоточиться на создании визуального редактора.

(1) Что касается вашего вопроса о реализации - я думаю, что дублирование компонентов и их изменение для соответствия AsyncAPI - правильный подход в краткосрочной перспективе. Причина в том, что позже достаточно легко провести рефакторинг для совместного использования компонентов в двух редакторах, но более того, в какой-то момент мы повторно реализуем весь пользовательский интерфейс Studio в React. Так что любые серьезные усилия, которые мы прилагаем в текущей реализации Angular, будут потрачены впустую. Лучше сделать что-нибудь быстро, ведь потом все равно придется переделывать.

(2) Я согласен с тем, что это не сложно с технической точки зрения, но оно долгое и кропотливое. :) Я думаю, что имеет смысл разделить реализацию на несколько PR - надеюсь, мы сможем разделить работу и между несколькими участниками.

@fmvilas Находится ли редактор в открытом исходном коде AsyncAPI Playground (я предполагаю, что да), а также его можно легко интегрировать в другие инструменты, такие как Apicurio Studio?

(если да, любые указатели на документацию с инструкциями были бы замечательными)

Спасибо, @EricWittmann !

Сначала я быстро взглянул на игровую площадку AsyncAPI, но, похоже, в NodeJS есть серверные компоненты. Так что я подумал, что интеграция будет не такой простой ... поэтому я исследую способ редактора ;-)

Я смогу уделить этому больше времени к концу недели ... Если вы не против, я попробую отправить первый PR-бюллетень в начале следующей недели. Должна быть предусмотрена возможность редактирования основной информации ( Version , Contact , License и Tags ), а также предварительный просмотр Channels в левом столбце.

Это открытый исходный код, вы можете найти его здесь . Однако мы работаем над гораздо лучшим вариантом с автозаполнением, ошибками, сообщаемыми в самом редакторе путем «подчеркивания» неправильных строк и столбцов и т. Д. Это фактически тот, который мы видели в AsyncAPI Hub , который в конечном итоге заменит Playground. Это еще не открытый исходный код, но он будет очень скоро, до конца года точно, и это делается в React с использованием редактора Monaco (редактор, поддерживающий VS Code).

Но, учитывая, что вы используете Angular в Apicurio Studio, я не уверен, что это будет полезно. Я слышал, что можно комбинировать React и Angular, но, честно говоря, никогда не пробовал.

Спасибо @fmvilas - в конечном итоге мы тоже перейдем на React (это в процессе). Требуются ли для нового редактора AsyncAPI какие-либо серверные компоненты или это чисто клиентский React? И предназначен ли он для встраивания в другие проекты?

Мы никогда не думали, что другие могут быть заинтересованы во встраивании этого, но это должно быть легко сделать, потому что это уже изолированный компонент, так что да, мы можем сделать его легко встраиваемым. Компонент является полностью клиентским React, поскольку Monaco не поддерживает рендеринг на стороне сервера.

Первый PR для начальной загрузки редактора! См. # 1280

А вот еще один на # 1285 ;-)

Очень скоро мы должны включить поддержку AsyncAPI по умолчанию (я считаю, что в настоящее время эта функция по умолчанию отключена).

Привет, @EricWittmann, и все!

Вот еще один: поддержка Operation, Message, OperationTrait и MessageTrait. См. # 1313 ;-)

Все детали каждой концепции еще не полностью реализованы в графической форме, но структура есть.

Всем привет!

В эти выходные нашел время для некоторых новых улучшений: вот еще один PR # 1382.

Теперь мы можем создать новую операцию, установить тип полезной нагрузки и заголовков, а также предоставить примеры (теперь полезно, когда мы можем напрямую имитировать AsyncAPI с помощью коннектора Microcks 😉)

@EricWittmann, как вы его включаете?

Для контейнера apicurio-studio-ui вам необходимо установить для переменной среды APICURIO_UI_FEATURE_ASYNCAPI значение "true" (как строку, а не логическое значение), @ alizard0 .