We already have lots of languages for describing event-driven applications such as Message Sequence Charts, Statecharts as well as a myriad of other types of specifications languages part of UML but also simple DSL syntax.
Why reinvent the wheel? What does this add to the current state of the art? I can't even find a "Related Work" section on their site.
The idea itself is sound, having an agreed specification allows others to build tools around this specification. (i.e. auto-generation, integration). In theory, this makes development easier. OpenAPI achieved this and is now widely used in various tools including Amazon API Gateway.
The types of diagrams you listed above are great for describing software in useful ways, but none of them are rigid enough to spec out an async API.
I still need to review this spec to fully understand it, so I'm not promoting AsyncAPI. I like the motivation behind it.
Websites can be embellished and misleading, also don't give a real sense of popularity and community support. I think a github repo is a thousand times better than a well "designed" landing page
This looks vaguely relevant so figured I'd ask the question here.
I'm working on what can be pretty well reduced to an AST builder. I have nodes of certain types which come with a set of relevant properties as well as the set of types that you're allowed to nest. I'm looking for a markup language to express these schemas so that I can generate the UI components (given parent node X, generate a widget with a form that can be used to submit legal children) and perform validation (given AST tree coming from the client, validate it server-side before persisting it)
Currently using JSON schema but it's very verbose. Any ideas?
cuelang is great for this, I highly recommend spending some time. It's not the easiest to on board yet, jump in slack though and we'll be happy to help.
Documentation is also clearly expecting the user to read the page on a desktop device. If you are part of the project, please check it out.
Interesting concept!
This is really interesting. I only knew of OpenAPI, but my project's going to have both HTTP / REST APIs and WebSockets. I didn't even know this existed. Thanks so much for sharing!
It's wild that this has been around since at least the middle of last year. I went searching for a way to define service boundaries for event driven systems and settled on a YAML structure that looks very similar.
I ended up trashing it and going for something more fluent, which I think could easily generate AsyncAPI YAML. Maybe I'll add that to the list of issues on my little side project.
Perhaps GraphQL could be used instead for some use cases. It's already got a specification that's been in use for several years, and has an execution model that goes beyond the basic request/response model. https://graphql.org/learn/execution/
I'm surprised many people don't understand your comment - I had the same thoughts. gRPC provides a very nice way to describe event driven microservices using their "stream" keyword. It allows the implementation to be async, blocking, or future based. You get access to a very rich ecosystem such as bazel's grpc \ proto rules, junit rules, grpc-web for streaming to the browser, out of the box support from istio / envoy, etc.
You're right. My fault here. It should actually be possible to define a gRPC streaming API (never tried). The only missing thing for me is the protobuf compatibility though.
If you mean protobuf, here's a link to the discussion on why it wasn't included in v2.0.0. That said, we'll explore adding non-JSON formats (like XSD and protobuf) to the specicification this year.
protobuf is just the serialization format gRPC is the replacement for HTTP and presumably asynchronous HTTP requests. Still not sure what their point is.
That use case would seem to be better served by creating a new standard that references the other standard for its IDL and serialization format, and general semantics, while having a separate standard for any websocket-specific details.
That avoids having to amend the original standard for each new variation. If you get enough variants (probably in the neighborhood of 2-4), then it makes sense to go back and supersede the original standard by breaking out the high-level layers each into their own standard that's designed for inclusion in other standards. That way, for instance, your async-Bluetooth standard doesn't have to refer to any document that gets bogged down in HTTP/1.1-specific messaging semantics. It's not worth re-factoring your standards stack the first time you reuse a standard, but you don't want some big spaghetti tangle of standards, either.
Why reinvent the wheel? What does this add to the current state of the art? I can't even find a "Related Work" section on their site.