[Draft] Developer Experience Working Group - Vision & Capabilities

[Amzani]

Meaning of DX (Developer Experience)

The developer experience is primarily about minimizing developers' friction when it comes to how they interact with AsyncAPI specification and tooling. We mainly target consumers (not contributors or maintainers).

To know more about my perspective on DX you can read my blog post

Capabilities

To think in terms of what our users are trying to achieve, let's delve into this initial list of capabilities split into 4 stages

1. Design: This is the initial stage where the AsyncAPI specifications are conceptualized, defined, and shared.
2. Develop: In this stage, developers create a code implementation, documentation, or any relevant asset from AsyncAPI files.
3. Deploy: In this stage, developers deploy their applications, update their AsyncAPI files with runtime operational information (e.g Server...), provision an infrastructure and perform API contract testing
4. Evolve: In this stage, developers update their AsyncAPI applications based on new requirements.

We will focus for now on these tools and design phase

• CLI
• Studio
• VS-asyncapi-preview
• Jasyncapi-idea-plugin

Note: please feel free to review them.

Design

CLI

• [x] Can create a new AsyncAPI file from a local template
• [x] Can create a new AsyncAPI file from a remote template
• [x] Can validate an AsyncAPI file against default recommended spectral rules
• [ ] Can validate an AsyncAPI file against custom spectral rules
• [x] Can render AsyncAPI documentation
• [x] Can support local workspace (context)
• [ ] Can support shared workspace
• [ ] Can share my AsyncAPI file
• [ ] Can sync my local AsyncAPI file with a remote system (e.g registry)
• [ ] Can publish my AsyncAPI file in a schema registry

Studio

• [x] Can create a new AsyncAPI file from a template
• [ ] Can create a new AsyncAPI file from a remote template
• [ ] Can edit an AsyncAPI file via code editor
• [ ] Can create/edit an AsyncAPI file via visual block editor
• [x] Can validate an AsyncAPI file against default recommended spectral rules
• [ ] Can validate an AsyncAPI file against custom spectral rules
• [x] Can render AsyncAPI documentation
• [ ] Can support local workspace (partial - local storage)
• [ ] Can support shared workspace
• [x] Can share my AsyncAPI file
• [ ] Can sync my local AsyncAPI file with a remote system (e.g registry)
• [ ] Can publish my AsyncAPI file in a schema registry

VSCode Extension

• [ ] Can create a new AsyncAPI file from a template
• [ ] Can create a new AsyncAPI file from a remote template
• [ ] Can edit an AsyncAPI file via code editor
• [ ] Can create/edit an AsyncAPI file via visual block editor
• [ ] Can validate an AsyncAPI file against default recommended spectral rules
• [ ] Can validate an AsyncAPI file against custom spectral rules
• [x] Can render AsyncAPI documentation
• [ ] Can support local workspace (partial - local storage)
• [ ] Can support shared workspace
• [ ] Can share my AsyncAPI file
• [ ] Can sync my local AsyncAPI file with a remote system (e.g registry)
• [ ] Can publish my AsyncAPI file in a schema registry

IntelliJ IDEA Extension

• [ ] Can create a new AsyncAPI file from a template
• [ ] Can create a new AsyncAPI file from a remote template
• [ ] Can edit an AsyncAPI file via code editor
• [ ] Can create/edit an AsyncAPI file via visual block editor
• [ ] Can validate an AsyncAPI file against default recommended spectral rules
• [ ] Can validate an AsyncAPI file against custom spectral rules
• [x] Can render AsyncAPI documentation
• [x] Can support local workspace (partial - local storage)
• [ ] Can support shared workspace
• [ ] Can share my AsyncAPI file
• [ ] Can sync my local AsyncAPI file with a remote system (e.g registry)
• [ ] Can publish my AsyncAPI file in a schema registry

Vision

• Remove the friction in the capabilities we are already supporting
• Support missing capabilities
• Monitor and share our DX metrics

DX metrics

• Time to First API Design (onboarding)
• System errors (friction)
• MTTR (friction)
• AsyncAPI 3.x adoption

How do we measure success

WIP

[ivangsa]

For VSCode Design I would suggest adding:

• [ ] Can open in the browser as a web extension: so it would work in gitpod or github codespaces, for instance, typing . while in a github repo opens a web instance of vscode that could install and run the extension

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart: