Are you wondering what changes have or are happning to the AsyncAPI tooling? Look no further! Here are the highlights of the changes that have happened in weeks 30-32
Time to introduce continous code generation for .NET libraries!
Are you wondering what changes have happened to the AsyncAPI tooling for the past months? Then look no further, here are the highlights and all of the changes that have happened!
Finally time to tie the last two posts together to explain how to achieve continuous code generation for TypeScript libraries
As part of achieving continuous code generation, one of the core issues is how to do versioning for the generated libraries. More precisely, how do you ripple effect version changes accurately - and in a manner that avoids non-caught breaking changes?
In principle, the goal is simple, changes made to the AsyncAPI files will automatically generate and release generated libraries, sounds easy right?
Wondering how you can create a setup that enables interactions with game servers by just installing a library? This blog post answers that question on a high abstraction level.
Enforcing reusability is great when you want to design your AsyncAPI documents, but what about when you want to use it in tooling?
Continuing, part 2 focuses on advanced Spectral rules and functions to enforce the GamingAPI consistency guidelines.
Based on your consistency guidelines, how do you enforce them? This can easily be done through Spectral.
With a version strategy in place, how do you put it into practice?
This post introduces the initial set of governance guidelines and sets the foundation for building the APIs.
Why NATS and how is it setup for GamingAPI?
How can you do versioning with AsyncAPI and what goes into selecting a versioning strategy?
I have always loved the server side of gaming, but we have no platform that enables easy integration with them. AsyncAPI to the rescue?
I have never embraced social media platforms, but I need a place where my thoughts can linger