This is another entry on my bi-weekly update 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 :)
2.4 release is getting closer!
It is a work in progress to find out all the possible PR’s that it will be included. For now, feat: added server variable object as reusable object is the first candidate and will be merged into the release branch soon.
Deprecation of messages. Does it sound interesting to you?
A message header to signal deprecation issue has been retaken by Erik Wilde. The idea would be to set a standard message header to indicate that the message contains deprecated payload. If you find it useful, please write your thoughts on the issue. 👀
“Remote and local servers” issue needs your help!
The idea around “Defining a collection of applications” has been discussed even more.
The recording for the last live session that has been held on this topic can be found here.
After the session, more feedback was shared on the issue that is worth checking with all of you who are interested in this topic.
During the last
3.0.0 meeting, Jonas Lagoni has suggested that it won’t make sense to include this into
3.0.0 spec release. Also, Fran Méndez suggested that it might make sense to create a different new spec for this matter.
Worth checking that part of the live stream here.
A way to document a guaranteed compatibility mode for produced messages.
Sometimes you might need to specify a compatibility mode for types of schema changes on your messages. This is pretty common for Avro. Thorsten Hake is asking Is there a way to document the guaranteed compatibility mode for produced messages? and suggesting that it might be a good idea to have the ability to document such compatibility mode.
Looking for ideas on how to implement it! 💡
Two new Spec
3.0 live meetings have been held 📹.
spec also had some more activity
- Vladimir Gorej, as per this comment, is gonna retake the work on Remove $ref field from Channel Item Object in next breaking change version (3.0.0) 🚀
- Dale Lane did a super great job updating the documentation regarding the Spec release process. You can find the updated documentation here: https://github.com/asyncapi/spec/blob/master/RELEASE_PROCESS.md
- Thorsten Hake opened a new issue to Clarify usage or URN for an AsyncAPI spec id and suggested to drop the current usage of URNs in the spec, suggesting to drop them by a different approach. Your thoughts are welcome! 💡
- Sergio Moya suggested a new git branch naming convention for the release branches at Use next branch for next minor releases, so we can reduce some of the pain points we are facing today during the release process.
- Andreas Lindhé is asking for a simple AsyncAPI example document based on AMQP, as we have for MQTT. Do you want to help Andreas Lindhé? ✍️
All Schema definitions are now split out into separate files
Jonas Lagoni did a fantastic job splitting all the schema definitions into separate files so contributing to them becomes more manageable.
It is pending to be released (very soon), but the work is done and merged (you can see the PR here).
v2.13.1 got released! 🎉
It includes the fix: force object type for message trait’s headers by Maciej Urbańczyk.
It got rewriten into TypeScript 🚀
New version for Solace binding is out! 🎉
Michael Davis updated the Solace binding with feat: add topicSubscriptions to direct destinations, which is adding
topicSusbscriptions field in the topic, so you can define a list of topics that the client subscribes to.
Shall we move binding JSON Schema files to the main JSON Schema repository?
Move binding JSON schema files to main JSON schema repository got revived again, and a discussion around where the JSON Schema files for bindings should be located was started. Please join! 👀
Migration to TypeScript has been started + new Parser API!
Worth mentioning this is not only a migration to TypeScript, but also a complete rewrite of the
parser-js, adopting finally the Intent-driven API of Parser-API, which a POC was created a few weeks ago as well (See this PR).