Plenty of discussion at the recent LEAP 2.0 API governance conference focused on HTTP APIs, RESTful and synchronous communication. But brave new frontiers such as AI and event-driven APIs also entered the arena. Leading the discussion of AI governance in an event-driven world was Lukasz Gornicki, Executive Director of the AsyncAPI Initiative.
We’ve rounded up some of Lukasz’s fascinating insights below, with a particular focus on:
- How you can position AsyncAPI documents at the heart of your event-driven API governance
- How you can move from implementing to updating AsyncAPI documents
- The rewards that you reap when you do so
Event-driven API governance
You may have started out with HTTP APIs, but modern ecosystems demand that you deal with different protocols. Luckily, AsyncAPI is here to make your life easier.
AsyncAPI documents contain plenty of details that you can include in your AsyncAPIs, then add governance around the content of the documents:
- Info: The info object is where you can specify if your application is a producer or consumer, what its name is, which version it is and all the other basic details about your app.
- Server object: This is where you can describe in detail where you connect and to which broker to start consuming or publishing messages, along with the security needed for a given broker.
- Channels object: This is for your topics, queues and so on. It’s where you define the messages for consumers and producers that go through a specific topic. You can add plenty of details, from what kind of messages to what schemas are available (JSON, Avro for Kafka and so on).
- Operations: Here is where you can add business details such as producing events and sending them to a specific broker or receiving them.
Implementing AsyncAPI governance
This abundant information makes implementing your API governance easy, enabling you to focus on strategy and educate and engage stakeholders from the outset. You’ll need an inventory early on too (because in reality you never start from scratch), as well as discussions around code first versus design first approaches. After this, you’ll have your first AsyncAPI document, which you can put in your developer portal.
Updating AsyncAPI versus reality
It’s after you publish your AsyncAPI document to the developer portal that API drift starts. You have this large YAML (because event-driven architectures are complex), that developers won’t really want to touch – because who wants to edit YAMLs? So you end up with AsyncAPI documents that aren’t updated or suffer really poor quality updates.
Discouraging though this is, there’s a neat solution that you can use to address it: AsyncAPI as a config for infrastructure.
Here, the developer uploads the AsyncAPI documents, packed with details about the broker, topics, schemas and so on, and pushes it to a “bouncer” that checks all the rules, linters, name conventions and the like. It checks overall quality and that everything is as it should be.
The bouncer can also take the contents of the AsyncAPI document and use it to (for example), get you access rights to a given channel in the broker. It could also configure a topic for you, because everything is already in the AsyncAPI document.
Another thing the bouncer can do is take advantage of a schema registry – your central place in the runtime where you store your schemas (so producers and consumers can validate messages in real-time in the runtime). The bouncer can grab your updates from the AsyncAPI document and register a new schema in the schema registry.
This approach means it’s important for developers to take care of the quality of the AsyncAPI document. If they don’t, for example by not adding information on a new topic or schema, then the applications they deploy using that topic or schema won’t work.
With your developers thus incentivized to keep the AsyncAPI document up to date, you get a handy bonus; the bouncer takes the always-updated document and puts it in the developer portal, providing excellent transparency (while also keeping management happy).
A wide range of organizations are already using AsyncAPI I production to configure the topology of the broker for their teams: Raiffeisen Bank, Kuenhe+Nagel, Postman, LEGO Group, Bank of New Zealand and Morgan Stanley, to name a few. If you want to work with Postman Workspaces internally as a team, for example, you’ll need to create an AsyncAPI document to get proper access.
The diagram below shows how organizations such as Raiffeisen Bank and Kuenhe+Nagel are doing this with Kubernetes. Everything is purely DevOps self-service, meaning all teams need to do is focus on creating beautiful Async API documents.
Managing event-driven APIs with Tyk
Want to discover more about getting the best from your event-driven APIs? Then it’s time to check out Tyk Streams, a powerful new Tyk APIM platform feature that enables you to securely expose, manage and monetize your real-time event streams and asynchronous APIs.
