Apicurio-studio: Capaz de oferecer suporte ao padrão AsyncAPI no editor

Adoraria ver um editor visual Apicurio para AsyncAPI. No momento, este projeto não tem largura de banda de engenharia para tal esforço. :(

@EricWittmann obrigado pela resposta. Tentarei encontrar algum tempo para trabalhar neste recurso se não for tão difícil ...

Bem, eu acho que adicionar suporte para AsyncAPI é uma enorme quantidade de trabalho. A primeira tarefa provavelmente seria implementar uma camada de analisador / modelo para ele. Para OAI, fiz isso aqui:

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

Portanto, esse é provavelmente um bom lugar para começar - talvez um novo repositório como asyncapi-ts-core .

Se você está pronto para esse tipo de coisa, seria ótimo! Eu precisava começar a pensar na melhor maneira de conseguir apoio asyncapi para o resto de Apicurio. Existem várias considerações nas várias páginas da IU.

Pelo que vale a pena, o AsyncAPI está começando a ganhar força adicional. Portanto, fornecer suporte para ele em Apicurio está subindo na lista de prioridades. :) Sem ETA ou algo assim AINDA - mas espero que possamos começar a fazer algum progresso nesta área.

É bom ouvir essa notícia, @EricWittmann , obrigado. Eu gostaria de participar, se tiver tempo suficiente.

FWIW, agora temos um analisador para AsyncAPI 2.0.0 . Estamos discutindo sobre a migração para o Typescript. Seria ótimo ter uma lista de tarefas do que precisa ser feito para ter o AsyncAPI no Apicurio. Podemos ajudar :)

Isso é interessante, @fmvilas - obrigado pelo ponteiro. Na verdade, construímos nossa própria implementação de modelo de dados unificado para AsyncAPI e OpenAPI aqui: https://github.com/Apicurio/apicurio-data-models

Essa biblioteca é escrita em Java e transpilada em Typescript para que possamos usá-la em nosso back-end e também diretamente em nossa IU. Ele também possui vários recursos, como suporte total ao visitante, um mecanismo de transformação operacional simples, etc ...

Para a parte mais interessante do seu comentário - tarefas que precisam ser feitas para ter AsyncAPI no Apicurio. :) :) Acho que a grande novidade agora é provavelmente o suporte ao editor. Em última análise, gostaria de ter paridade de recursos com nosso editor visual OpenAPI (que inclui validação e suporte de edição simultânea). No entanto, acho que uma boa contribuição (talvez temporária) a curto prazo seria integrar o editor AsyncAPI baseado em texto existente no Apicurio. Isso seria muito legal e iria um longo caminho. Eu poderia ver um futuro onde o editor baseado em texto e o editor visual são opções com suporte. Na verdade, um usuário da comunidade pediu isso - seus desenvolvedores sênior não gostavam do editor visual e, em vez disso, queriam um editor de texto. Vai saber.

Além do editor, teria que pensar na lista de tarefas. Mas todo o resto seria incremental no topo do editor (por exemplo, geração de projeto).

Para a parte mais interessante do seu comentário - tarefas que precisam ser feitas para ter AsyncAPI no Apicurio. :) :)

Eu te escuto :)

Bem, como você disse, vamos começar com algo fácil / mais fácil. Avisarei você assim que tivermos alguma largura de banda para colaborar. Obrigado!

A colaboração seria incrível, com certeza. Nesse ínterim, se você tiver alguma documentação sobre como incorporar o editor AsyncAPI a outros aplicativos, provavelmente poderia criar algo interessante como um POC muito rapidamente.

Estou me referindo ao editor encontrado no playground aqui: https://playground.asyncapi.io/

Eu não olhei para isso ainda - então não tenho certeza se ele foi construído para ser facilmente aproveitado em outros aplicativos, mas se sim, espero que não seja difícil de importar e usar. Isso seria um longo caminho para reivindicar (pelo menos inicial) suporte AsyncAPI dentro do Apicurio Studio.

Olá @EricWittmann ,

Passei algum tempo investigando hoje qual seria o custo de adicionar editor gráfico para AsyncAPI e cheguei ao início de um resultado recentemente. Veja a captura de tela abaixo - recriei a mesma estrutura do OpenAPI e adicionei o editor de código que já temos, então já temos paridade de recursos em comparação com o que temos hoje. Comecei com o exemplo AsyncAPI que adicionei anteriormente.

Alguns pensamentos e perguntas que gostaria de compartilhar:

• Primeiro no lado da implementação: o novo componente do editor já estava presente e eu prossigo seguindo isso duplicando os componentes existentes em sua contraparte AsyncApi* . Na maioria das vezes, apenas substituir OasDocument por AaiDocument , isso não é tão elegante ... No entanto, eu apenas arranhei a superfície e haverá diferenças mais importantes entre as 2 especificações ... Você prefere manter desta forma e ter 2 conjuntos independentes de componentes ou tentar mutualizar mesmo se houver muitos if document.isOpenApi() ou if document.isAsyncApi() ao longo do código? O que você acha ?

• 2º no processo. Como você disse antes, pode ser um grande esforço ... Não é tecnicamente difícil, mas longo e meticuloso ... Então acho que não terei paciência e nem seja viável implementar todos os editores de especificações antes de comprometer qualquer coisa. Prefiro ver isso como uma tarefa iterativa em que posso preencher algumas peças começando com altas prioridades ( Channels , DataTypes , Messages , Examples ; - )) e, em seguida, diminuir as prioridades ( Servers , Traits e assim por diante ...). O que você acha ? Seria correto dividir a implementação em várias solicitações pull?

Eu realmente ficaria feliz em ajudar, pois você deve ter visto que o Microcks agora suporta simulação AsyncAPI (e teste em algumas semanas). Portanto, pode ser uma virada de jogo ter o suporte do Apicurio e permitir cobrir os principais estilos de especificações de API modernas.

cc @fmvilas ;-)

Em primeiro lugar - parabéns pela adição do suporte AsyncAPI no Microcks! Eu vi que foi adicionado recentemente.

Eu tenho algumas idéias sobre isso. Em primeiro lugar, acho que pode fazer sentido tentar incorporar o editor AsyncAPI Playground ao Apicurio Studio se isso for tecnicamente "fácil". :) Isso seria uma vitória rápida e nos daria um suporte "beta" razoável para a edição de documentos AsyncAPI no Apicurio Studio.

Depois disso, poderíamos nos concentrar na criação de um editor visual.

(1) Quanto à sua pergunta sobre a implementação - acho que duplicar os componentes e modificá-los para caber no AsyncAPI é a abordagem certa a curto prazo. O motivo é que é fácil refatorar mais tarde para compartilhar componentes entre os dois editores, mas mais do que isso é que iremos reimplementar toda a IU do Studio no React em algum ponto. Portanto, qualquer grande esforço que fizermos na implementação Angular atual será em vão. Melhor fazer algo rápido, já que terá que ser refeito mais tarde de qualquer maneira.

(2) Concordo que o esforço não é tecnicamente difícil, mas é longo e meticuloso. :) Acho que faz sentido que a implementação seja dividida em vários PRs - espero que possamos dividir o trabalho entre vários colaboradores também.

@fmvilas O editor é encontrado no código aberto AsyncAPI Playground (presumo que sim) e também pode ser facilmente integrado a outras ferramentas como o Apicurio Studio?

(se sim, qualquer indicação para a documentação de como fazer seria incrível)

Obrigado @EricWittmann !

Dei uma olhada rápida no playground AsyncAPI primeiro, mas parece ter componentes do lado do servidor no NodeJS. Então eu estava pensando que a integração não seria tão fácil ... é por isso que eu exploro o jeito do editor ;-)

Devo poder dedicar mais tempo a ele até o final da semana ... Se estiver tudo bem para você, tentarei enviar um primeiro PR no início da semana que vem. Deve ser possível ter as informações principais editáveis ​​( Version , Contact , License e Tags ), bem como uma visualização somente leitura de Channels na coluna do lado esquerdo.

É código aberto, você pode encontrá-lo aqui . No entanto, estamos trabalhando em um muito melhor com preenchimento automático, erros relatados no próprio editor "sublinhando" as linhas e colunas erradas, etc. É na verdade aquele visto no AsyncAPI Hub , que eventualmente substituirá o Playground. Este ainda não é de código aberto, mas será muito em breve, antes do final do ano, com certeza, e é feito no React usando o editor Monaco (o editor que alimenta o VS Code).

Mas, visto que você está usando o Angular no Apicurio Studio, não tenho certeza se será útil. Ouvi dizer que é possível combinar React e Angular, mas honestamente nunca tentei.

Obrigado @fmvilas - no final das contas iremos converter para o React também (que está em andamento). O novo editor AsyncAPI requer algum componente de servidor ou é apenas React do lado do cliente? E tem a intenção de ser incorporado em outros projetos?

Nunca pensamos que outras pessoas poderiam estar interessadas em incorporá-lo, mas deve ser fácil de fazer porque já é um componente isolado, então sim, podemos torná-lo facilmente incorporável. O componente é React puramente do lado do cliente porque Monaco não suporta renderização do lado do servidor.

Primeiro PR para inicializar o editor a caminho! Veja # 1280

E aqui está outro em # 1285 ;-)

Muito em breve, devemos habilitar o suporte AsyncAPI por padrão (o recurso está desativado por padrão, eu acredito).

Olá @EricWittmann e tudo!

Aqui está mais um trazendo: Suporte para Operação, Mensagem, OperaçãoTrait e MessageTrait. Veja # 1313 ;-)

Todos os detalhes de cada conceito ainda não foram totalmente implementados na forma gráfica, mas a estrutura está lá.

Olá a todos!

Encontrei algum tempo neste fim de semana para algumas melhorias: aqui está outro PR # 1382.

Agora podemos criar uma nova operação, definir o tipo de carga útil e cabeçalhos, bem como fornecer exemplos (útil agora que podemos simular diretamente AsyncAPI com conector Microcks 😉)

@EricWittmann como você o habilita?

Para o contêiner apicurio-studio-ui, você precisa definir a variável de ambiente APICURIO_UI_FEATURE_ASYNCAPI "true" (como string, não booleano), @ alizard0 .