This is another entry on my bi-weekly update (yes, this time the range is a little more extensive) about the AsyncAPI Spec and parsers.
Note This is not an official AsyncAPI update but a personal summary I volunteer to do.
What do I mean by AsyncAPI Spec and parsers update?. As most of the work around the AsyncAPI Spec is not only related to https://github.com/asyncapi/spec, each update will include the most significant recent activity from the following repositories:
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 :)
“What it could mean to support multiple applications” live discussion
This is one of the “hot topics” around the
v3.0.0 of AsyncAPI Spec. For this reason, on the 28th of February, Jonas Lagoni hosted a live discussion about this topic. It was a great way to get feedback from the community about the following issue: Defining a collection of applications.
The video recording is available here.
Your feedback is needed to keep iterating on this idea, so I encourage you to write yours and share it on the the issue.
Solving publish/subscribe confusion on spec 3.0 requires noticeable changes
People shared more thoughts and feedback in the Proposal to solve publish/subscribe confusion. Some users raised a few concerns around Developer Experience, particularly in the fact that messages would be declared inside the channelsand how operations refer to them. Worth reading the thread. This topic was discussed in the Spec 3.0 Meeting (link to the right minute) as well.
Please join the thread and share your thoughts! 👀
Spec 3.0 meeting
- 16th of February 2022:
- Next one is on the 2nd of February 2022, 16 UTC:
Documentation for the release process is being improved!
Dale Lane is working hard to document the current spec release process properly. As Dale was the last release coordinator, he had all the new and fresh knowledge to do such a task. The Draft PR can be found here. Please consider reviewing it (even though it’s in Draft state) and giving feedback! 👀
Server variable objects will be reusable in v2.4.0!
Thanks to Daniel Kocot who pushed for feat: added server variable object as reusable object, server variable object will be reusable in v2.4.0. All PRs are now reviewed and accepted but blocked until we start the v2.4.0 release process:
We’ve got a new Code Owner for the Spec!
I usually don’t mention new additions to the Code Owners list on repositories, but I believe this should be an exception; It is not common at all to have a new Code Owner on the Spec :) If you wonder who became a new Code Owner of the Spec, I won’t let you wait for that long:
Dale Lane is the new Code Owner 🎉🚀! And the reason for that is very well explained here, thanks to Lukasz Gornicki.
As a side note, Dale is also now, consequently, Code Owner of the spec-json-schemas repository.
Shall we move binding JSON Schema files to main JSON Schema repository?
Move binding JSON schema files to main JSON schema repository got revived, and a discussion around where the JSON Schema files for bindings should be located was started. Please join! 👀
Integrating Spectral (by Stoplight) in parser-js
Spectral is a JSON/YAML linter (Not a JSON Schema linter/validator). The point is that it provides a mechanism for writing and running custom validation rules (one of those can be running AJV for validating against JSON Schema).
This is important because it could simplify most of the job we do nowadays in the
parser-js, which validates against JSON Schema, and also runs custom validations, which could be ported to Spectral.
Maciej Urbańczyk started playing around with this to validate the idea ASAP. If we can validate it, it would mean that our current parser-js parse logic will be drastically simplified, becoming almost just a wrapper of Spectral, with our custom rules. He also created the following PR on Spectral repository: feat(rulesets): support 2.1.0, 2.2.0, 2.3.0 AsyncAPI versions. It has already been merged 🚀!
Here is the issue Integrate stoplight/spectral in parser where you can track the progress, also join the efforts! 🙌
Intent-Driven API slowly progressing
More work has been done regarding the Intent-Driven API planned for the next version of the
parser-js (and for all future parser implementations). Sergio Moya has been implementing some suggestions and improvements to the following mock: feat: initial intent API implementation. Even though this PR won’t be probably be ever merged, this is intended to help us, from the more practical point of view, define the API that we want to use across all parsers (See Parser-API).
This would be included in the next major version of the
parser-js, especially for giving support (retroactively) for the
v3.0.0 spec release.
parser-js also had some more activity
- 🐛 Bug reported by Semen: Inconsistent behavior of message/messages/hasMultipleMessages
- 👀 Ritik’s PR: fix: throw meaningful errors is waiting for another review!
- 👑 Nektarios is championing the bug References are bundled before validated
New four versions got released! 🎉
Maciej Urbańczyk has been working hard on the
converter-js repository and has just released the following versions:
v0.7.1contains a bug fix regarding an inconsistent behavior when converting from JSON. Here is the PR with the change: fix: handle JSON
v0.7.2contains a bug fix regarding an error with a wrong cleanup of the field
namefrom parameters located in components. Here is the PR with the change: fix: remove name field from parameter shape (from 2.0.0-rc2 version)
v0.8.0changes the way the errors are handled. Now, they are being thrown instead of being just logged. Here is the PR with the change: feat: throw errors, do not log them
v0.9.0adds a new
-oflag that allows saving the output into a file by passing a path to it. Here is the PR with the change: feat: add output flag