AsyncAPI open meeting, Tuesday Feb 16 2021 8AM UTC

[derberg]

This is the meeting for the AsyncAPI Special Interest Group (SIG). You're invited to join us and ask questions. The meeting takes place on alternate Tuesdays. Recordings from the previous meetings are available in this playlist on YouTube.

This time we meet at 8AM UTC

If you want to make proposals for the specification and/or the tooling, please reach out in our Slack workspace or just leave a comment below.

Join this mailing list to get an always-up-to-date invite to the meeting in your calendar.

Attendees

Join us if you want to know more about AsyncAPI! The meeting is open to the public.

Agenda

Don't wait for the meeting to discuss topics that already have issues. Feel free to comment on them earlier.

1. Q&A
2. (Leave a comment below to add your item to the agenda)
3. Q&A

Notes

We had 11 guests!

• We talked about the idea from @fr3shw3b. @fmvilas shared what he worked on for hub.asyncapi.com. Then with @Ugbot we drifted to the topic of sniffing the traffic coming to brokers to generate AsyncAPI files. And at the end we talked about plans for the AsyncAPI proxy that @smoya will lead at AsyncAPI. -> that was a super interesting discussion
• We talked about the AsyncAPI CLI and helped offered by @jotamusik to work on the CLI. In conclusion, we created a new repo https://github.com/asyncapi/cli and the work will start there in the issues by drafting the initial design and scope of the CLI. Join now to shape it together, so far we know we love https://github.com/vadimdemedes/ink (but this is just a technical sugar)
• We mentioned the initiative from @dalelane on Specify Avro encoding approach bindings#40 and work from @lbroudoux on Specify how Avro schema ID is serialized on Kafka bindings#41 to improve Kafka bindings. Have a look at the proposal from Dale https://gist.github.com/dalelane/3931c17b14c51fa4a1cf25496237d188 and join the discussion.

It was a good meeting, even though I have a feeling that half of the people probably took a nap afterward 😄

Recording

https://youtu.be/t5gmL-_gcxU

[fr3shw3b]

I'll be joining the meeting to give an introduction to a project I'm working on that will utilise AsyncAPI and figure out how best I can contribute back to the AsyncAPI project.

The project I'm working on

I'm currently building an API hub service for teams to collaborate on designing and documenting different types of APIs in a single seamless experience. The plan is to support AsyncAPI and OpenAPI . The project would be akin to SmartBear's SwaggerHub or Oracle's apiary but without focusing only on RESTful HTTP APIs.

The project is driven by the following:

• Seeing the current API hubs on the market, their cost and limitations.
• Seeing there is a lot left to be desired in terms of design and UX.
• Need for accessibility in the API docs space.

The project seeks to provide the following from the start:

• A single place to manage, design and document a variety of different types of APIs.
• An intuitive way to search, navigate and explore larger systems with lots of APIs.
• A collaborative experience akin to tools like Notion.
• An experience that will let you work offline with ease and is resilient in poor network conditions.

In the future:

• Intelligent integrations with productions systems to identify differences and provide developers with the tools to help identify issues and ensure synchronisation between docs and implementation over time. This is not about generating docs from code or code from docs but more about synchronisation with code and cloud configuration.

AsyncAPI pieces of interest

• Building out specifications for the server and channel bindings for Cloud services (AWS SNS, SQS etc.)
• Whether Google Cloud Pub/Sub could be something that gets some server and channel bindings.
• Contributing to increasing full support for event-driven protocols.
• Contributing to the AsyncAPI tooling where it makes sense to.