AsyncAPI Spec and parsers update (30 Nov - 31 Dec 2021)

I plan to write periodic updates about the AsyncAPI Spec and parsers every ~2 weeks (I hope you are ok with it).

Note 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 :)

Spec

Spec v2.3.0 work is progressing!

• 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:
  • https://github.com/asyncapi/website/pull/512
  • https://github.com/asyncapi/spec/pull/681
  • https://github.com/asyncapi/spec-json-schemas/pull/142
• Sergio Moya is championing Allow servers and channels to be defined inside components. The RFC is in Stage 2 Draft (even though it mentions Stage 0 Strawman), and most probably going to advance its stage to Stage 3 Accepted and be included in 2.3.0 release. For this reason, PR’s are opened and targeting 2022-01-release branch:
  • https://github.com/asyncapi/spec/pull/665
  • https://github.com/asyncapi/spec-json-schemas/pull/133
  • https://github.com/asyncapi/parser-js/pull/430
• Michael Davis is championing Add Solace bindings to the list of supported bindings in the spec. The RFC is in Stage 2 Draft and will probably advance its stage to Stage 3 Accepted and be included in the 2.3.0 release, especially considering that the PR that had Solace binding got merged almost two months ago. The following PR got opened and targeting 2022-01-release branch:
  • https://github.com/asyncapi/spec-json-schemas/pull/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.

Spec v3.0.0 work is slowly progressing!

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 kind property. 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.0 changes) has been annotated in https://github.com/asyncapi/parser-js/issues/401. And your feedback is needed!
• Also, regarding the Parser-API repo, some new important issues have been opened by Jonas Lagoni:
  • Clarify the intention of server URL.
  • Clearly define how traits should be applied.
  • Define how to handle unknown schema and message id’s.
  • Define how hasX need to be interpreted.
  • Define how to handle derferencing.
  • Define how to handle schemaFormats.

You can find a list (grooming pending) of candidates to be included in v3.0.0 at https://github.com/asyncapi/spec/milestone/18.

Spec also had some more activity

• 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.yml example with change clientId type on kafka operation to schema.

• Lukasz Gornicki also worked on streetlights-kafka.yml example 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 messageID did a baby step.

  • Sergio Moya has opened a few issues to guide people on the work that has to be done in :
    • https://github.com/asyncapi/spec-json-schemas/issues/131
    • https://github.com/asyncapi/parser-js/issues/414

  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 :)

spec-json-schemas had some important activity

• 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.0 release. A discussion about it can be found on the issue.

parser-js v1.13.1 is out + some important issues and updates!

• 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:
    • fix: type of json() method by Fran Méndez.
• 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.

avro-schema-parser got a PR to fix a bug

fix: avro parser now handles record reuse in definitions by Jonathan is waiting for your review!

Metrics

Commits

Commits by repo:

Issues

Issues Backlog

Pull Requests

Pull Requests opened:

Pull Requests closed:

Pull Requests Backlog