Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Draft] Developer Experience Working Group - Vision & Capabilities #1214

Open
12 of 46 tasks
Amzani opened this issue May 16, 2024 · 2 comments
Open
12 of 46 tasks

[Draft] Developer Experience Working Group - Vision & Capabilities #1214

Amzani opened this issue May 16, 2024 · 2 comments
Labels

Comments

@Amzani
Copy link
Contributor

Amzani commented May 16, 2024

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

Note: please feel free to review them.

Design

CLI

  • Can create a new AsyncAPI file from a local template
  • Can create a new AsyncAPI file from a remote template
  • Can validate an AsyncAPI file against default recommended spectral rules
  • Can validate an AsyncAPI file against custom spectral rules
  • Can render AsyncAPI documentation
  • 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

  • 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
  • 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

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
  • 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
  • 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

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
Copy link
Contributor

ivangsa commented May 21, 2024

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

Copy link

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

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 ❤️

@github-actions github-actions bot added the stale label Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants