Apicurio-studio: 能够在编辑器中支持 AsyncAPI 标准

我很想看到 AsyncAPI 的 Apicurio 可视化编辑器。 目前，该项目没有进行此类工作的工程带宽。 :(

@EricWittmann感谢您的回复。 如果不是那么困难，我会尝试找一些时间来研究这个功能......

好吧，我认为添加对 AsyncAPI 的支持是一项巨大的工作。 第一个任务可能是为它实现一个解析器/模型层。 对于 OAI，我在这里做到了：

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

所以这可能是一个很好的起点——也许是一个像asyncapi-ts-core这样的新存储库。

如果你愿意做那种事情，那就太好了！ 我需要开始考虑在 Apicurio 的其余部分中获得 asyncapi 支持的最佳方法。 跨各种 UI 页面有许多注意事项。

就其价值而言，AsyncAPI 开始获得一些额外的动力。 因此，在 Apicurio 中为其提供支持正在上升优先级列表。 :) 没有 ETA 或类似的东西 - 但希望我们可以开始在这方面取得一些进展。

很高兴听到这个消息，

FWIW，我们现在有一个AsyncAPI 2.0.0的

这很有趣， @fmvilas - 感谢您的指点。 我们实际上已经在这里为 AsyncAPI 和 OpenAPI 构建了我们自己的统一数据模型实现： https :

该库是用 Java 编写的，并被转译为 Typescript，因此我们既可以在后端使用，也可以直接在 UI 中使用它。 它还具有各种功能，如完整的访客支持、简单的操作转换引擎等......

关于您评论中更有趣的部分 - 需要完成的任务才能在 Apicurio 中使用 AsyncAPI。 :) :) 我认为现在最重要的事情可能是编辑器支持。 最终，我希望与我们的可视化 OpenAPI 编辑器（包括验证和并发编辑支持）具有同等的功能。 但是，我认为短期内一个不错的（也许是暂时的）贡献是将现有的基于文本的 AsyncAPI 编辑器集成到 Apicurio 中。 那会非常酷，而且会大有帮助。 我可以看到未来基于文本的编辑器和可视化编辑器都是受支持的选项。 我实际上有一个社区用户要求这样做 - 他们的高级开发人员不喜欢可视化编辑器，而是想要一个文本编辑器。 去搞清楚。

除了编辑器，我还得考虑任务清单。 但其他一切都将在编辑器之上递增（例如项目生成）。

关于您评论中更有趣的部分 - 需要完成的任务才能在 Apicurio 中使用 AsyncAPI。 :) :)

我听到了:)

好吧，正如您所说，让我们从简单/更容易的事情开始。 一旦我们有足够的合作空间，我会立即通知您。 谢谢！

合作肯定会很棒。 同时，如果您有一些关于如何将 AsyncAPI 编辑器嵌入到其他应用程序中的文档，我可能会很快敲出一些有趣的 POC。

我指的是在此处的操场上找到的编辑器： https :

我还没有研究过——所以我不确定它是否被构建为可以在其他应用程序中轻松利用，但如果是这样，那么希望它不难导入和使用。 这对于在 Apicurio Studio 中声明（至少是初始）AsyncAPI 支持大有帮助。

嗨@EricWittmann ，

我今天花了一些时间调查为 AsyncAPI 添加图形编辑器的成本是多少，最近才开始得出结果。 请参阅下面的屏幕截图 - 我重新创建了与 OpenAPI 相同的结构并添加了我们已有的代码编辑器，因此我们已经拥有与今天拥有的功能相同的功能。 我从我之前添加的 AsyncAPI 示例开始。

我想分享的一些想法和问题：

• 第一个在实现方面：新的编辑器组件已经存在，我通过将现有组件复制到它们的AsyncApi*副本来追求这一点。 大多数情况下只是将OasDocument替换AaiDocument ，这不是那么优雅......但是我只是触及了表面，两个规格之间会有更重要的区别......即使代码中有很多if document.isOpenApi()或if document.isAsyncApi() ，您是否更愿意保持这种方式并拥有 2 组独立的组件或尝试相互化？ 你怎么认为 ？

• 2、流程上。 正如你之前所说，这可能是一项巨大的努力......技术上不难，但漫长而细致......所以我认为我不会有耐心，也不可能在提交任何内容之前实施整个规范编辑器。 我宁愿将其视为一项迭代任务，我可以从高优先级（ Channels 、 DataTypes 、 Messages 、 Examples ;- )) 然后降低优先级（ Servers ， Traits等等......）。 你怎么认为 ？ 可以在许多拉取请求上拆分实现吗？

我真的很乐意提供帮助，因为您可能已经看到 Microcks 现在支持 AsyncAPI 模拟（并在几周内进行测试）。 因此，拥有 Apicurio 支持并允许涵盖现代 API 规范的主要样式可能会改变游戏规则。

抄送@fmvilas ;-)

首先 - 祝贺在 Microcks 中添加了 AsyncAPI 支持！ 我确实看到这是最近添加的。

我对此有一些想法。 首先，我认为如果技术上“容易”，尝试将 AsyncAPI Playground 编辑器嵌入到 Apicurio Studio 中可能是有意义的。 :) 这将是一个快速的胜利，并将为我们在 Apicurio Studio 中编辑 AsyncAPI 文档提供合理的“测试版”支持。

之后，我们可以专注于创建可视化编辑器。

(1) 至于你关于实现的问题——我认为复制组件并修改它们以适应 AsyncAPI 是短期内正确的方法。 原因是稍后重构以在两个编辑器之间共享组件很容易，但更重要的是，我们将在某个时候在 React 中重新实现整个 Studio UI。 因此，我们在当前 Angular 实现中所做的任何重大努力都将被浪费。 最好快速做一些事情，因为无论如何以后都必须重做。

(2) 我同意这个努力在技术上并不难，而是漫长而细致。 :) 我认为将实现拆分为多个 PR 是有意义的 - 希望我们也可以将工作分解为多个贡献者。

@fmvilas编辑器是否在 AsyncAPI Playground 开源中找到（我假设是）并且还能够轻松集成到 Apicurio Studio 等其他工具中？

（如果是的话，任何指向 howto 文档的指针都会很棒）

谢谢@EricWittmann ！

我首先快速浏览了 AsyncAPI 游乐场，但它似乎在 NodeJS 中有服务器端组件。 所以我在想集成不会那么容易......这就是我探索编辑器方式的原因;-)

到周末我应该可以花更多时间在它上面...如果你觉得没问题，我会尝试在下周初提交第一个 PR bu。 它应该是可能有可编辑的主要信息（ Version ， Contact ， License和Tags ），以及作为一个只读预览Channels在左侧列。

它是开源的，你可以在这里找到它。 但是，我们正在开发一个更好的自动补全功能，通过“下划线”错误的行和列在编辑器中报告错误等。它实际上是在Monaco 编辑器（支持 VS Code 的编辑器）完成的。

但鉴于您在 Apicurio Studio 使用 Angular，我不确定它会有所帮助。 我听说可以将 React 和 Angular 结合使用，但老实说从未尝试过。

谢谢@fmvilas - 我们最终也将转换为 React（正在进行中）。 新的 AsyncAPI 编辑器是否需要任何服务器组件，还是纯粹的客户端 React？ 它是否打算嵌入其他项目中？

我们从没想过其他人会对嵌入它感兴趣，但应该很容易做到，因为它已经是一个独立的组件，所以是的，我们可以让它轻松嵌入。 该组件纯粹是客户端 React，因为 Monaco 不支持服务器端渲染。

用于引导编辑器的第一个 PR！ 见#1280

这是#1285 处的另一个 ;-)

很快我们应该默认启用 AsyncAPI 支持（我相信该功能目前默认关闭）。

嗨@EricWittmann和所有人！

这是另一个带来的：Operation、Message、OperationTrait 和 MessageTrait 支持。 见#1313 ;-)

每个概念的所有细节还没有完全实现为图形形式，但框架已经存在。

大家好！

本周末有时间进行一些新的改进：这是另一个 PR #1382。

我们现在可以创建新的 Operation，设置 Payload 和 Headers 类型以及提供示例（现在我们可以使用 Microcks 连接器直接模拟 AsyncAPI 很有用😉）

@EricWittmann你如何启用它？

对于 apicurio-studio-ui 容器，您需要将APICURIO_UI_FEATURE_ASYNCAPI环境变量设置为"true" （作为字符串，而不是布尔值）， @alizard0 。