It's feedback time 👀

[Pakisan]

Hey, it's Pavel, maintainer of AsyncAPI Java bindings and plugin for JetBrains

I want to ask you to share your experience with JAsyncAPI and JAsyncAPI IDEA plugin to better understand your expectations and your opinion about the current state

I welcome any feedback, whether it's positive or negative

For example:

• I don't use AsyncAPI and I don't have plans, because of
• I was using AsyncAPI, but due to , I have stopped using it
• I am currently using AsyncAPI in my projects and I aim to change several aspects

[erosb]

Hello @Pakisan thank you for raising this topic.
I don't use AsyncAPI, because I haven't found enough java tooling (at least, when I looked for it last summer).

My usecases are the followings:

Verifying consumed messages in tests

Given I'm writing a test, that sends a message to my application (and verified it is processed properly)
When my test runs
Then I want to verify that the message sent from my test conforms to the AsyncAPI specification, so that I make sure both my test and production code conforms to the AsyncAPI spec.

Rationale: it is possible to write both production code and test code in a way that the test is passing; still, without additional test tooling, nothing ensures that the messaging conforms to the AsyncAPI spec, which will yield an error only after my tests are ran and my service is integrated with an other service, publishing that message. I want to prevent such situation by validating both the production and test code against the AsyncAPI contract.

Verifying published messages in tests

Given I'm writing an integration test
When my application sends a message
Then I want my integration test to verify that the outgoing message conforms to the AsyncAPI spec

Rationale: same as above, but this time my service is the publisher (and not the consumer) of the message

Verifying received messages in production

Given my service is running
When an incoming message received by my service
Then I want to check if the message payload, metadata, subscription etc. conforms to my AsyncAPI specification.

Rationale: when something goes wrong, when 2 services integrate via messaging, it is important to know which party broke the AsyncAPI contract.

Summary: I need proper validators pluggable into the frameworks I use (partly JMS, party Azure Service Bus client library). I would like to use these to do contract-first development & verify conformity to the AsyncAPI contract, when I integ-test my service in isolation (without the other publisher/consumer services). I'm much less interested in code generators.

In case of REST interfaces (OpenAPI), I could put it together the contract-first development flow with openapi4j, RestAssured and a servlet filter, but for messaging (AsyncAPI) I haven't found the necessary tooling.

[Pakisan]

Hi @erosb, thanks for great scenario!

Did you try Microcks? You can mock OpenAPI/AsyncAPI specifications to receive "live" request or events to ensure that your application will handle them in correct way?

[erosb]

Thank you @Pakisan we will definitely look into it!

[Pakisan]

If you are using Spring, you can check out SpringWolf to generate specification from your code, at runtime and expose web view to interact with configured broker

I wrote demo, for conference, https://github.com/Pakisan/podlodka-java-crew-4. I need to finish Microcks part(push docker compose), but anyway is good point to start

[ChMThiel]

I'm contributor of a quarkus-extendsion, that scans the code for MicroProfile-Annotations for messages and generates AsyncApi-files from that. I found your lib very usefull!
Now i wanted to update from 2.0 to 3.0 and i wondered why all Maps are no longet typed (e.g. channels, servers, etc. in class AsyncAPI)...