Replies: 2 comments 2 replies
-
|
I guess there is already a VS code extension. If I am not wrong @Amzani. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, you a right that we have VS code extension, also as IDEA plugin |
Beta Was this translation helpful? Give feedback.
-
|
This story is about how to provide best tools to work with our specification and develop EDA apps. When I wrote this message, I was thinking about new studio era. I believe than we can provide great cloud editor with specification registry to help folks write/edit/share more specs. That's why I proposed to co-operate and build common standard for interaction with studio It will help to improve UX.
On other way, we also, can provide Swiss army knife for EDA enthuthiasts to work locally with specifications, brokers, cloud providers from their machine. That's why I have started editor development Yeah, we have bunch of not related tools to do this things, but we can wrap them into few freemium products to start earn money and be less dependent from donations, for example |
Beta Was this translation helpful? Give feedback.
-
|
@Pakisan Regarding the new studio era, we can still build on top of what @fmvilas started here #634
|
Beta Was this translation helpful? Give feedback.
-
This is the continuation of a slack conversation on how to integrate with IDE extensions (e.g JetBrain IDEA plugin)
Hey, folks, hope you are doing well!
I want to receive feedback from all of you. Some of you already known me, some not, yet). I'm maintainer of java bindings and JetBrains IDEA plugin
On every job place, where I come, I adopt our specification to describe, deploy, configure and monitor async APIs
I believe that we, as community, can provide best tools for our specification. That's why I created bindings, to provide ability to use our spec in Spring or Quarkus frameworks, and wrote plugin for writing or editing it inside wide range of JetBrains IDEs
Yep, it facilitated dive into our specification, but it's only beginning of long way
When I work with specification, I prefer to decompose it and reuse common parts. I thing you are doing same way)
I tried to implement this functionality inside plugin, but I decided that it's too painful to relay on external environment with long release cycles and undefined priority for bugs related with OAS, AAS
So I decided to craft from a scratch handy editor for AsyncAPI and CloudEvents(in a future).
I splitted it to phases:
create dumb visual editor to create or choose and edit specifications
extend editor, with plugins, to studio to be able to:
communicate directly with Microcks, Apicurio Registry, Kafka, RabbitMQ, ...
create, edit and share specification components with folks, who are you working with
validate trough Spectral, for example
For me it's an desktop application, not SaaS, because of this reasons:
it's easier to use local tools, when you are selling something, from you to C level or internal teams
it's strange to integrate with wide range of brokers or integrations from web app or agents, running on remote machine, instead of direct way
You can check out POC here - https://github.com/Pakisan/asyncapi-editor/tree/master
I'll be appreciated for any feedback
Got your point @Pakisan
For JetBrains+Studio Journey I mean describing the current steps, we might have multiple design journeys, depending on the developers skills (beginner, Intermediate, expert)
for instance, I assume for a beginner
I learn about AsyncAPI (reading docs...)
I go to Studio or JetBrains plugin, prototype my specification and preview docs
If using JetBrain plugin I manually load the AsyncAPI spec into studio so I can share it with my colleagues
Once we have the current journey (steps) we can suggest a future journey that we want to push for.
The idea is to have some consistency for all the IDEs extensions and how they should work with studio.
Developers can also benefits from UI consistency (e.g Visual/bloc designer have the same look and feel)
I’m not sure that’s good idea to draw design trough users story. For me it’s clear strategy with known benefits, after realisation. And it’s more best practices, not user expectations
It’s clear, for me, that specifications must be stored in single place, registry for example, to provide single point of truth. After that I can split it to components and use the everywhere:
api gateways
load balancers
boilerplate code generation, like start.spring.io - choose needed integrations and receive ready to use clients and/or projects from templates
…
To achieve this, for example, I can use studio.asyncapi.com. Where I can store specs, components and share it with folks and automation tools, also as publish/retrieve from any external solution, like plugin for IDE
tldr;
Not to start from user stories, like As user I want to …, but provide methodology through JTBD. Now u have bunch of specs and here is what you can do with them now to facilitate your work
Beta Was this translation helpful? Give feedback.
All reactions