community icon indicating copy to clipboard operation
community copied to clipboard

[Draft] Developer Experience Working Group - Vision & Capabilities

Open Amzani opened this issue 9 months ago • 2 comments

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

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

Amzani avatar May 16 '24 14:05 Amzani