The future of the Studio

[magicmatatjahu]

Currently the Studio is developing faster and we have plans to add more features, such as:

• support for multiple applications
• building specifications with blocks
• validate examples of message payloads

However, it may not be clear to some people involved in the development of the Studio, especially our community, what we want to achieve with the Studio and what its future is.

In this discussion we should clarify the purpose and future of the Studio and (optionally) point out the flaws of the current solution. There are voices that Studio itself should be just a front-end application with server addition or in another hand an application written in NextJS, or with similar technology.

I think each person should describe how they see the studio in a few months and what their options are and then we'll take all the best parts and try to put them together. They may be completely different and that is not a problem.

If you want to add any suggestions for the new tool please create a new discussion in the ideas topic :)

I will start with myself:

• Studio should be used to edit the AsyncAPI document.
• The user should be able to see all the errors that has in the current AsyncAPI document, any validation errors and should be able to define own rulers under the linter - similar to Stoplight Studio. Currently we don't have a linter but should have (idea).
• user should be able to see preview of documentation which is creating in minimum 2 ways - html and visualiser what exact flow is in his specification. We currently support this by React-component and Visualiser
• in addition to creating documentation in the editor, the user should also be able to create specifications in other ways. Currently I have an idea for so called form builder, and block builder. With the form builder you will be able to add new sections to the specification using forms (e.g. like here, but more generically - Asyncapi builder #135). Block builder should look like the current Visualiser but the user should be able to create data nodes and combine them - What is next for the visualiser? Need your help! #213
• Studio should support multiple applications to edit/render/valid (Support multiple applications #195) etc. We should go with direction of panels/tabs - Tabs and split panels like in VSC #167
• some parts of Studio should support drag and drop functionality to increase DX
• Studio should support and implement in a DX friendly way all our tools like diff, cupid, chatbot, bundler etc
• Studio should work in two versions, with connection to local server (server-api) via cli and as regular web application (as currently):
  • in case of local server user should open given folder where has AsyncAPI files are and update should be bi-directional, changes of local file should be visible in app and vice versa
  • use should have also possibility to download browser-side project as zip with all docs/common files
• Studio should support all our official templates and, if possible, other community-contributed templates - mainly generator support and modelina support
• we should have a tool to validate sample payloads - Enable validation of an example payload #200
• we should have a tool to test broker/microservices flow - What is next for the visualiser? Need your help! #213 (comment)
• Studio should be able to share specifications via url - Share feature proposal #127
• Studio should be able to register extensions - maybe there we should also show extension catalog and related to it tools?
• Studio should be able to define/register plugins to extend functionality
• theming (dark, light, contrast)

Very futuristic plans:

• native application using electron - Provide cross platform app #172

Of course, the studio capabilities themselves should be documented as much as they can :)

cc @boyney123 @mcturco @fmvilas @derberg @jonaslagoni @alequetzalli @smoya @Barbanio

[quetzalliwrites]

Yes! Studio is amazing and I would love to document it soon.

I'm going to place it's docs under the /Tools content bucket when I finish the IA changes from the GH issue of asyncapi/website#350.

When I'm ready to start adding tooling docs, I will have SO MANY MORE QUESTIONS on its features.

[magicmatatjahu]

I'll be waiting 😄

[BOLT04]

I don't have a whole lot of context on what Studio is currently, nor of its implementation. But here are the points I agree the most with you on what Studio should be able to do 🙂:

• Studio should be able to register extensions - maybe there we should also show extension catalog and related to it tools?
• Studio should be able to define/register plugins to extend functionality
• Studio should support multiple applications to edit/render/valid

There is something else I'm thinking about, but my thought process might be just wrong 😅. I was thinking if Studio would be a similar tool to Postman, where teams can have multiple workspaces and manage multiple collections, document APIs, etc. Or perhaps AsyncAPI tools could later integrate very nicely with Postman and other tools, and Studio would be one of the apps that integrate cupid, visualizer, generators, validator, parser, etc.

Currently, it seems Studio is perhaps similar to what Swagger editor is to OpenAPI spec 🙂, so it's the place to do what you mentioned: Studio should be used to edit the AsyncAPI document. In the future, maybe there are plans to increase the number of real-world examples, or even make it open source 😄. I think the Slack example comes from here but yeah, it could be interesting to have some type of "marketplace" to ease the onboarding process of new teams to the AsyncAPI spec. The block builder could really help with this too, but sharing examples and specifications would be cool to 👍

[magicmatatjahu]

@BOLT04 Thanks for feedback! :) At the moment we want to focus on tool integration. We are not currently thinking about an application like Postman, because we don't want to store user data etc, maybe in the future, we'll see :)Your ideas are really cool, but as I wrote, our priority is to add integration to as many tools as we have and improve them. The rest will bring time :)

[BOLT04]

awesome! Yeah, integration of more tools and standards is great 💯.
Thanks for the response 😃

[boyney123]

Thanks @magicmatatjahu some interesting thoughts there for sure, and I agree with most of them (going to be hard to come up with a UX that allows so much functionality!... cc @mcturco )

Here are my thoughts to add to the pile

• Studio is a place where people can explore their current AsyncAPI docs but also create them (you covered)
• Studio should be accessible for deep-dive but also High-level interaction
  • Certain features of studio may need deep dive into the Spec like Plugins, Extensions etc, so we gotta think about those usecases
• Studio should allow someone to create AsyncAPI from nothing, and help them create their files
  • You covered this with drag and drop stuff, and other things, also the new templates solution helps this, but maybe there is more we can do (not sure yet)
• Studio should allow us to connect to their brokers and send test payloads/messages
  • Would be great (in theory) to connect to people's brokers maybe and actually send messages to things and show responses and logs here. Although this might require server-side application...
• Studio could allow us to deploy the Service/Application (from AsyncAPI file) somewhere they can test it and actually use it?
  • What if the Studio allowed us to deploy peolpes EDA? For example if you have a Kafka AsyncAPI file we could in theory deploy that? Maybe people like Upstash could support us here and allow free open source solutions?

---

There are voices that Studio itself should be just a front-end application with server addition or in another hand an application written in NextJS, or with similar technology.

Yeah it's interesting one... from what I read above I do star to wonder if Server Backed application is going to be best for the long hall... with so many features that may require filesystem, backend api stuff etc.... Not sure but it's my gut feel at the moment.

[BOLT04]

Studio should allow us to connect to their brokers and send test payloads/messages

that would be awesome!! Currently I thought studio did that, on that play button from the event visualizer 😅. But being able to test in the browser with all the pieces being mocked out would be really helpful.
That way I don't need to use cloud offerings or setup a broker, publisher and subscriber to test my event-driven flows, etc 😃

[magicmatatjahu]

Studio should allow us to connect to their brokers and send test payloads/messages

👍🏼 Swagger UI has similar functionality to test HTTP based application by request to given path based on OpenAPI. We should remember about that idea, but in our case (in AsyncAPI case) we have a bindings so one new protocol == one new integration to test, or there is some place to make it generic, I don't know, I'm not specialist in that area 😅

Studio should allow someone to create AsyncAPI from nothing, and help them create their files

Atm we have templates, but we should also have forms builder (like in Spotlight studio) and drag and drop blocks (based on Visualiser). More things/idea are more than welcome :)

Studio could allow us to deploy the Service/Application (from AsyncAPI file) somewhere they can test it and actually use it?

Fine idea, but first we should focus on creating/editing spec, not for that features 😅 TBH I don't know how this should work.

[derberg]

I think that Studio's first goal should be to help users to work with AsyncAPI documents (yes, many), to manage them:

• edit
• create
• see diffs
• use optimizer
• use bundler
• use generator
• use modelina
• use cupid and extend this concept of visualized view of the system, and adding new elements with clicks
• at some point when ready integrate chatbot and AsyncAPI Blocks (scratch like AsyncAPI creation)

So in short, Studio is where we integrate all the tools we have to make it easier for folks to get along with AsyncAPI files

the rest like 👇🏼 are cool and nice to have but I would definitely put it on a side to not lose focus:

• testing
• integration with external systems for deployments

[fmvilas]

For both we should base logic on JSON Schema structure to make them "version agnostic".

We can discuss details once we start the implementation but I'd not generate forms with JSON Schema. Ideally, the UI should be focused on the user and solving the user's needs. If we generate them with JSON Schema, the UI will resemble the structure of the AsyncAPI document, which I think the UI should abstract.

[magicmatatjahu]

We can discuss details once we start the implementation but I'd not generate forms with JSON Schema. Ideally, the UI should be focused on the user and solving the user's needs. If we generate them with JSON Schema, the UI will resemble the structure of the AsyncAPI document, which I think the UI should abstract.

I agree, but there I had in mind that we should use JSON Schema to create mapping/constraints for validation. In case of blocks, we can use that JSON Schema to create relationship between given kind of blocks like message, operation etc, that you can connect message with operation block etc, so I don't want to base full implementation on JSON Schema but only some parts.

[mcturco]

Just wanted to jump in here and say that I think it is an excellent idea to make Studio the "hub" of all tools where the user can apply the benefits of each tool in one place. Why make people have several different workspaces when you can streamline all features into one? After all, developers usually only have 2 screens in their workspace, so one can be dedicated to their local project, and the other for Studio 😄

[mcturco]

For both we should base logic on JSON Schema structure to make them "version agnostic".

We can discuss details once we start the implementation but I'd not generate forms with JSON Schema. Ideally, the UI should be focused on the user and solving the user's needs. If we generate them with JSON Schema, the UI will resemble the structure of the AsyncAPI document, which I think the UI should abstract.

I agree with @fmvilas, even though most devs will know what to do with JSON schema, the point of the tools are to provide a quick and easy way to reach the user's end goal. You have to also assume that there are devs who are just getting started in the API space, so we want to create solutions that require as little coding as possible. Might there be a way to create a UI for all the options we want to provide?

[fmvilas]

Might there be a way to create a UI for all the options we want to provide?

@mcturco that's what I'm arguing against precisely 😄 Something like jsonforms.io can generate forms from a JSON Schema definition but that would only create a form that maps our spec, i.e., you would have to understand the spec anyway. My point is that we should abstract it away so people interact with EDA/API concepts they know or expect and an AsyncAPI file is generated behind the scenes.