What’s new on AsyncAPI? Lots!
It’s been a long time since I don’t write here. Lots of things have happened since November 2017. At that time, AsyncAPI used to be my pet project, and I couldn’t predict what it is nowadays and — more importantly — what’s becoming.
I was working at Hitch (a.k.a. API Changelog) together with my friends Bruno Pedro, Luke Miller, Dulce de la Rosa, obfuscatedgeek, Thierry Templier, and Inés Luna. One of the main features of Hitch was the API changelog and, as you may already have realized, a changelog is a sequence of events (changes, to be more precise.) Therefore, our microservices had to be reactive or event-driven.
While we were working on our shiny and new event-driven architecture, I realized there were lots of tools and methodologies we used for HTTP APIs that we didn’t have when building message-based architectures. We were encouraging our customers to use OpenAPI definitions for their APIs, but we had nothing for asynchronous APIs. Like many people, I tried using OpenAPI doing an ugly hack: Paths were AMQP topics, GET was SUBSCRIBE, and POST was PUBLISH. It more or less did the job for documentation, although I had to create our custom documentation generator to show information correctly. However, generating code is a different story. I also managed to do it, but my OpenAPI documents were full of patches and specification extensions only to make it work. It was then when I headed to the OpenAPI repo on Github in search of a solution and, surprise! I wasn’t alone. There were some people already asking for MQTT and AMQP support. The answer was always the same: this is not the scope of the specification. And I couldn’t agree more.
So what now? — I asked myself. It was clear there was a need. It was clear that OpenAPI was the industry standard for defining APIs in a machine-readable format. But, unfortunately, messaging was not part of their scope. So I thought: “Be brave, clone the whole specification, read it entirely, adapt it to your needs, and make it open source. What can go wrong?”. I was right, nothing went wrong, but reality facepalmed me. The specification was too biased to my use case, even though I tried to make it for everyone. Well, that wasn’t unexpected, to be honest.
Life happens — and it always catches you in the middle — so we joined New Relic to help them drive API integrations forward. If I recall correctly, it was more or less at that time when I received the first pull request from Mike Ralphson. OMG! Someone is not only using AsyncAPI, but he’s reading the whole specification! I couldn’t be happier! Mike was a fervid contributor of OpenAPI in these days, what led him to become a member of the OpenAPI TSC (Technical Steering Committee). I don’t know anyone who deserves it more than him — sorry, Darrel Miller 😜. Mike kept contributing to AsyncAPI and even adding support for it on his great Widdershins tool. He soon became one of the main contributors to the project. And still is!
Months after I joined New Relic, I felt horribly sick. I had no energy to continue working on A̶s̶y̶n̶c̶A̶P̶I̶ anything, so I had to stop for some months. Thanks to the fantastic public healthcare system we have in Spain, I managed to recover and get ready for the next milestone: I got married to my beautiful, patient, and definition-of-good-person girlfriend, Eva Morcillo. Finally, my 2018 was starting to be awesome!
A few weeks after we got married, I talked to Kin Lane and some other great API evangelists to help me manage the workload on AsyncAPI. I was getting too many questions on Slack, issues on Github, direct messages on Twitter, and — at the same time — I had to continue working on improving the specification and the tooling. All of these while I was working at New Relic. Crazy! It was too much for a single person to manage. It was then when Kin stepped in and published a blog post asking people to help drive AsyncAPI forward. Fortunately, the blog post got the attention of great people who were decided to join the initiative. Special thanks to Antonio Garrote, Chris Wood, Emmelyn Wang, James Higginbotham, Jonathan Schabowsky, Jonathan Stoikovich, Leon Stigter, Lukasz Gornicki, Matthew O’Riordan, raisel melian, Raji Narayanan, and Víctor Romero. I also want to thank Bill Doerrfeld from Nordic APIs, Mehdi Medjaoui (APIdays), Matt McLarty (A̶P̶I̶ ̶A̶c̶a̶d̶e̶m̶y, now MuleSoft), and Taylor Singletary (Slack API) for giving me the chance to show the world what AsyncAPI is.
Coming back to Kin’s blog post, I have to say its impact was good. It was so good that, on September, I had to interrupt my holidays because AsyncAPI was getting a lot of interest from different big companies, namely SAP, MuleSoft, Salesforce, TIBCO, Solace, and Slack. It was my turn to show commitment to the initiative, so I had to quit New Relic. Sad to leave but very happy for the reason.
And here we are today! Mike Ralphson and raisel melian joined me to maintain the project, providing extremely valuable help not only with the current specification, tooling, issue triaging, and support but in drafting what’s going to be AsyncAPI 2.0.0.
Join our Slack workspace or visit our Github repo for more information.
It’s been a great trip so far but I’m sure the best is yet to come. Onward!
Special mention goes to Bruno Pedro, a great friend and manager, who’s always been —and still is— coaching me. AsyncAPI has much more of him than what Github shows. I’ll be eternally thankful for your help and patience, Bruno.
Cheers! 🍻
