Hey all, The PactFlow team is conducting research on contract testing within an event-driven architecture context. We'd love to hear from you about your event driven architecture testing strategy in your workplace and how contract testing fits in your event driven projects. More specifically, we are looking at integrating tightly with AsyncAPI, to bring you all the great benefits of Pact alongside the benefits that specification-driven workflows can provide. By getting involved, you can help be in the driving seat and shape the future of contract testing We’ve got multiple ways you can get involved, - An easy to fill 5-min survey (open until 27th March) - Schedule a zoom call with PactFlow team - Join our developer preview programme - Vote or comment on our Public Roadmap card We appreciate your time and input! - Shuying & Yousaf from the PactFlow team!

So um…. what is AsyncApi?

Herro dude! It's a specification format for documenting message based services, similar to OpenAPI for REST

All powered by the AsyncAPI specification, the industry standard for defining asynchronous APIs.

Emphasis theirs. Colour me suspicious.

I haven't dug too far into their raison d'etre, but seems similar to the Swagger/OpenAPI. Machine readable specs, which can be leveraged by multiple tools, for multiple purposes We utilised it as a previous organisation in order to help document both their existing RESTful services with OpenAPI and the emergent event-based services that had been built, with AsyncAPI (which people felt familiar with due to exposure to Swagger/OpenAPI). We then built a centralised store where we could search across them, as the real business value spanned multiple services and it was hard to get a decent view across it

Yeah. Looking at the docs it seems a bit sparse, but clearly a good fit for people who like OpenAPI - you don’t have to learn much more, and your existing pipelines / generators etc wouldn’t have to change much

For those also not sure on what AsyncAPI is, you can check out their link here. https://www.asyncapi.com/ It's part of the Linux Foundation, as is the OpenAPI spec, so it is in decent hands. Industry standard (marketing speak) - it's definitely got a foodhold in the spec market but I don't think enough people are using it. (It's also free and open-source which is why I quite like it) - especially when thinking about building out demos showcasing hexagonal arch where you can show the business logic unaffected by using different transport mechanisms

Message validation in runtime

I reckon pact could do this. It would be excellent to have a drop in gateway / shadow proxy that would detect request / response pairs that aren’t covered by the pact

I really like the way msw does that, and totally agree

Ah yeah! I thought about building that for Case - it’s something that a lot of mobile developers would like

Colour me suspicious. (edited)

It’s definitely good marketing on their part, but given a bunch of industry titans have backed it it’s all but going to be. I think https://cloudevents.io/ is probably one competing version, but not really. If you can remember back to the early days of REST, there was WADL, RAML, blueprint and Swagger. Swagger one out for various reasons, and then was donated to the linux foundation. The fact AsyncAPI has been backed by pretty much all the likely suspects means there is unlikely to be a viable alternative. The real question is - will it get used? According to public data sources (notably SmartBear and Postman’s annual API surveys), the number of respondents who use it is 12-13%. I think there are reasons to be very skeptical of that number. For example, the actual usage of AsyncAPI in SwaggerHub is much smaller than that. Postman doesn’t yet support it in their IDE yet as far as I can see, but others like Stoplight do. That will no doubt drive some level of adoption. I’m (and the team) are mostly interested in that last question, how message pact provides value to teams today and what we could do to improve that