I plan to write periodic updates about the AsyncAPI Spec and parsers every ~2 weeks (I hope you are ok with it). This is not an official AsyncAPI update but a personal summary I volunteer to do.
What do I mean by AsyncAPI Spec ecosystem? As most of the work around the AsyncAPI Spec is not only related with https://github.com/asyncapi/spec, each update will include the most significant recent activity from the following repositories, which I consider them to be part of the same ecosystem:
- spec
- bindings
- extensions-catalog
- spec-json-schemas
- parser-js
- parser-api
- parser-go
- openapi-schema-parser
- raml-dt-schema-parser
- avro-schema-parser
- tck
- converter-js
- converter-go
This time, as an exception (it is the first one I do), I wanted to include updates from the whole month (30 Nov - 31 Dec 2021).
Feel free to ask me to include any other repository if you consider it makes sense. Also, in case you want to help me with these updates :)
- Dale Lane and Lukasz Gornicki are leading this release. The overall progress is tracked here. They created the following PRs that represent the scaffolding of the release branches:
- Sergio Moya is championing Allow servers and channels to be defined inside components. The RFC is in
Stage 2 Draft(even though it mentionsStage 0 Strawman), and most probably going to advance its stage toStage 3 Acceptedand be included in2.3.0release. For this reason, PR's are opened and targeting2022-01-releasebranch: - Michael Davis is championing Add Solace bindings to the list of supported bindings in the spec. The RFC is in
Stage 2 Draftand will probably advance its stage toStage 3 Acceptedand be included in the2.3.0release, especially considering that the PR that had Solace binding got merged almost two months ago. The following PR got opened and targeting2022-01-releasebranch:- asyncapi/spec-json-schemas#143 Once the previous is merged, ci scripts will generate a new release of @asyncapi/specs package. Then there will be one more PR coming on parser-js which will update that package to point to that new version.
As always, You can find some of the most critical progress on the AsyncAPI spec v3.0.0 release journal
- The Proposal to solve publish/subscribe confusion RFC is slowly being moved forward. Sergio Moya has taken the initiative to split this issue into smaller ones so they can be treated as independent RFCs. An example is the one already mentioned in the previous section: Allow servers and channels to be defined inside components. Some issues have been created so anyone else can also pick them anc champion them:
- Make channels field optional within an AsyncAPI file.
- Let channels be identified by an ID rather than their address.
However, we need more thoughts on how to handle the
kindproperty. Shall we drop that idea? Help is needed here.
- The Pros/Cons of implementing an Intent-driven API (as described in Parser-API) for the future Parser-JS version (the one that will adopt spec
v3.0.0changes) has been annotated in asyncapi/parser-js#401. And your feedback is needed! - Also, regarding the Parser-API repo, some new important issues have been opened by Jonas Lagoni:
You can find a list (grooming pending) of candidates to be included in v3.0.0 at https://github.com/asyncapi/spec/milestone/18.
-
Jonas Lagoni baked a new example of spec use-case to be used as AsyncAPI doc reference from now on. Here the PR, which is already merged.
-
Khuda Dad fixed the
streetlights-kafka.ymlexample with change clientId type on kafka operation to schema. -
Lukasz Gornicki also worked on
streetlights-kafka.ymlexample with extend example for kafka with x509 security, which is already reviewed and waiting for a last review and approval from the code owner Fran Méndez. -
The list of contributors shown in the spec repository is now showing only spec contributors thanks to this PR by Lukasz Gornicki
-
The work on redefine the trait inheritance behavior has been retaken by Simon Heimler.
-
Should we have freeze period on release process?. Maciej Urbańczyk is opening that debate and looking for more opinions on it.
-
add security at the operation level by sekharbans is moving most probably to RFC
Stage 2 Draft. -
docs(spec): fix the type and docs of Operation.message field by Vladimir Gorej is waiting for the last review so it can be merged.
-
Add Support for
messageIDdid a baby step.- Sergio Moya has opened a few issues to guide people on the work that has to be done in :
We need a champion for this feature, so please consider passing by and dropping questions. I (Sergio Moya) am more than happy to help you :)
- To ease maintainability of AsyncAPI JSON Schemas, Jonas Lagoni has been doing a rework on them, mainly splitting all definitions into different files they can be bundled later to provide a unique file to use. The PR is available here, and it has been going through several iterations. Some people have already reviewed it. As always, eyes are welcome and needed, so I encourage you to go and take a look!
- On the other hand, Lukasz Gornicki opened the issue remove js and go package and probably move JSON schemas should stay alone in the repo.
The TL;DR is that it has been proposed to create separate repositories for each different language implementation (Node and Go at this time) of that package instead of using monorepo. All those repositories will have an up-to-date copy of the JSON Schema definitions (via GH Actions). Work would start after
v2.3.0release. A discussion about it can be found on the issue.
- Two versions got released!
v1.13.0:- feat: add stringify function by Maciej Urbańczyk. More info why need that can be found here.
v1.13.1:
- Dimitrios Dedoussis discovered that there are Misleading validation errors for Security Scheme Objects. It needs further investigation so help is wanted!
- Work on Improve error handling in parser by Maciej Urbańczyk has been retaken after few questions and suggestions dropped by David.
fix: avro parser now handles record reuse in definitions by Jonathan is waiting for your review!
