A new year always comes with New Year's resolution, right? Folks from Bump.sh
Foundation and open governance model
As part of recently announced partnership with Postman, most core AsyncAPI maintainers joined Postman as employees. This change made it clear that now it is even more important what we planned in the past.
AsyncAPI must go into a "neutral ground" aka independent foundation that, among other things, will take over the AsyncAPI intellectual property.
Joining a foundation also means setting up an open governance model to ensure a single company's lack of dominance over the specification and its tools.
As communicated during our public meetings on 2nd of February or 19th of January, or our official Twitter account, Fran and I treat this topic as priority number 1.
At the moment, we are trying to figure out a governance model that:
- is as democratic as possible
- supports asynchronous decision-making process
- gives power to people that "work", not companies that "pay". In other words, it gives equal power to both, individual and corporate contributors
Now we spend a lot of time reading and reaching out to similar communities that went this path and know what booby traps to avoid to stay healthy. We hope to share something more concrete in the next update, in March.
New bronze sponsor
We kicked off this year with a new bronze sponsor. Thanks a lot to Bump.sh and their trust in the AsyncAPI Initiative, and being among the first ones adopting the AsyncAPI specification in their product.
Community continues to grow
My last post that summarizes the year 2020 was pretty clear that the community's size grew a lot. Well, it is January, and we see that not much has changed. We keep growing:
- we went over 1k users on Slack. Join now
- we went over 1.5k followers on Twitter. Follow us to be up to date with the latest news in the project
- we went over 1.4k stars on GitHub. If you like the project, express it
- we had several issues solved by the community members from different companies, including few new features. For more details, read Feature releases and community-driven changes section
RapidAPI Developer Survey
RapidAPI released the results of their developer survey. Reading it at the beginning of the year is like drinking a strong coffee in the morning - you get a good kick of positive energy for the rest of the year.
Spoiler alert -> number of developers using AsyncAPI in production tripled in 2020.
Feature releases and community-driven changes
- Pavel Bodiachevskii continues his hard work on asyncapi-java. Wait, it is finally not asyncapi-java anymore. Thanks to a suggestion from James Higginbotham it is all about jasyncapi now. Maven, Gradle and IntelliJ plugins are not published as a preview release under official AsyncAPI accounts. Please give them a try and share your feedback.
- React component:
- shows required flag for required props thanks to c-pius from SAP
- we have better DX in Web component thanks to Viacheslav Turovskyi
- Playground now shows much detailed errors thanks to Jorge Aguiar Martín from Lean Mind - es
- HTML template:
- CSS size decreased and introduction of Tailwind 2.0 thanks to Julian Schafer
- CorrelationId rendering thanks to Ludovic Dussart from IneatLab
TypeScript NATS template
We have a new template available. You can use this template to generate NATS client based on the AsyncAPI document for Node.js. Interesting fact: it is already using the new React render engine from the AsyncAPI Generator.
Next major feature is data model generation
We again invest big-time in the Generator. This time, it is all about making it super easy to generate a data model for templates, so the template developer doesn't waste much time on templating it and can focus on the template's main logic. In other words, it is all about enabling faster template development. Our progress looks good, and it seems like at the end of February, we should already have something that you can start using.
Feel free to share your thoughts in this issue.
Refactoring of our CI/CD
GitHub Actions is what powers our CI/CD. It is a great tool that you configure through a file stored in a repository. Things are just getting more complex when you want to use them in an organization with around 40 repositories (and growing). This is not a post about our internal organizational challenges and GitHub Actions limitations, so I will not bother you with details. The most important is to share that we are managing our GitHub workflows like a pro and if you are interested in more details, contact us.
So what changed that is meaningful for our community:
- We have two new channels in Slack workspace:
- #github-releases where you get information about all the releases from all the repositories
- #github-new-issues-prs where you get information about all new issues and PRs
- Whenever we have a major or a minor release in any repository, our bot automatically tweets about it
- All pull requests are now tested against Linux, MacOS, and Windows. For you, this means that we fixed a lot of bugs in tests and configurations that were blocking Windows users from smooth contributions
- Not used to Conventional Commits specification? now all pull requests have a dedicated check that lints your pull request titles and gives hints what you should fix
You contributed something to the JavaScript Parser, and you wonder what you have to do to see the change in the Generator? No need to wonder. Now, when we release any package, we also bump its version in all the other packages that depend on it. AsyncAPI bot is a super busy bot 🤖
The future of API specifications
Working with specifications is not easy because there are many of them. How do you know when to use which one? Just look at the concept of microservices architecture. Did you think that monitoring, scaling, and tracing is a challenge? What about specifications:
- you need a different spec for your backend that exposes GraphQL API to your frontend
- you need another spec to describe how a user can interact with your service using asynchronous communication
- you need a different spec to define how a user can interact with your service with REST
What about specs for describing your data model? What about if you use RPC and Protobuf? What if you use Avro? or maybe you only use JSON Schema.
Why do you have to define the same things over and over using different specs...
Something went wrong down the road, and we need to do something to save the chicken.
Watch Fran's presentation on the future of API specification. And don't stop there. We don't want only to admit we know about the problem and expect someone solves it. We want to fix it. Join us!
Public meetings
For notes and links to recordings, look into the below references:
Spoiler alert -> leading topic during the meetings was the status of AsyncAPI.
Next meeting is scheduled for Feb 16 2021 for 8AM UTC. Feel free to suggest a topic or such join to say hello.
Google Summer of Code
This month we want to apply for Google Summer of Code. We found two volunteers that agreed to mentor participants to work on some good stuff for the AsyncAPI tooling space. January was when we collected all the possible ideas that we would work on together with students. The list of ideas is completed. There are many good proposals there, and most of them won't make it to the event, so feel free to let us know if you want to work on them under the AsyncAPI umbrella.
Good read
- AsyncAPI and OpenAPI: an API Modeling Approach by Antonio Garrote
- API adoption is on the rise across all industries
- How Microcks Can Speed-Up Your AsyncAPI Adoption - Part 2 by Laurent Broudoux
- Simplify code generation with React by Jonas Lagoni and Maciej Urbańczyk
That was an exhausting month, but looking at what is happening around the project, you feel it was worth it. Let us see what February brings.
Photo by Nicolas Hoizey on Unsplash
