community
community copied to clipboard
[Draft] Developer Experience Working Group - Vision & Capabilities
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
- Design: This is the initial stage where the AsyncAPI specifications are conceptualized, defined, and shared.
- Develop: In this stage, developers create a code implementation, documentation, or any relevant asset from AsyncAPI files.
- 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
- 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