Status update (week 8, 2019)
Hey folks! It’s February 21st and I can’t be more excited to share the progress we made this week on the AsyncAPI Initiative.
Latest changes in the specification
- Added support for multiple schema formats. This change is a very significant one. AsyncAPI 2.0.0 will offer ways to define messages in multiple schema formats, e.g., JSON Schema, Protobuf, Avro, etc. And this was the last issue of the “Normalize topics and support multiple schemas” milestone.
- Restrictions on server scheme have been removed. The list of supported protocols was making it harder to evolve fast because including a new protocol to the list would require releasing a new specification version. It made sense in the beginning when I was the only one building tooling but, fortunately, that’s not the case anymore.
- Added an examples field to the server variable object. This was requested a long time ago. Having the ability to add examples of a server variable seems like a reasonable thing, right? Check out examples here.
- Security requirements have been moved to the server object. Since now you can have many servers, some of them may require different authentication/authorization mechanisms. For instance, you may have a password to connect to your production environment broker but don’t have any to connect to your staging environment broker.
Tooling roadmap and strategies
This week we started an effort to define and document how we’re going to implement the tooling for version 2.0.0. Since we now have added support for different schema formats (JSON Schema, Protobuf, Avro, etc.) and we want to provide support for multiple programming languages and we also want to add support for multiple protocols, it quickly becomes clear we need a strategy here. Just a simple calculation of 4 schema formats × 6 programming languages × 5 protocols, gives us a total of 120 parsers to maintain. We do need a strategy.
Summarizing, we’re going to create a pluggable parser in Go. Why Go? Because we want to compile the code as a C library so we’re able to import it from all the other languages. It means that with little effort we would be able to provide parsers for any language, which in turn will be just wrappers of the C library. We’ve also considered Rust as it’s much better compiling to C and produces a smaller binary but, after all, this is a community project and it’s easier for us to leverage the Go community than the Rust one. It doesn’t mean we’re ditching Rust. I’m sure we’ll create some components with Rust so we can make the community grow. And, who knows? Maybe eventually we’ll rewrite the parser in Rust if we think that makes sense.
AsyncAPI SIG meeting
We had our bi-weekly SIG meeting this week where I elaborated on our roadmap and strategies for tooling. And it’s now uploaded in our Youtube channel.
Donate
And last but not least, this week we’ve launched our Open Collective campaign to get funds so we can continue working on making more and better AsyncAPI. We’ve got different tiers, so everybody can show their love! ❤️
Donate here. Help Open Source projects.
See you next week, my friends! 👋
