4 ms·

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 sp

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.

jsdalton 7y ago
There appears to be far more details on the main website: https://www.asyncapi.com/ https://www.asyncapi.com/ Not sure why the Github repo was submitted.
- augusto-moura 7y ago
  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
  - verdverm 7y ago
    I'd like to see an example on either landing point, both preferably.
makstaks 7y ago
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. edit: typo
- MuffinFlavored 7y ago
  I don't quite get it. Why can't I just enforce schema validation in my pub/sub handlers? I see the YAML example completed here: https://www.asyncapi.com/docs/getting-started/servers/ https://www.asyncapi.com/docs/getting-started/servers/ asyncapi: 2.0.0 info: title: Hello world application version: '0.1.0' servers: production: url: broker.mycompany.com protocol: amqp description: This is "My Company" broker. channels: hello: publish: message: payload: type: string pattern: '^hello .+$' This looks like a thin wrapper around sending a message to a message queue. What's the gain? Where do you define what to do as a subscriber?
  - derberg 7y ago
    you have 2 operations in the spec, publish and subscribe. above example already tells you what to do as a subscriber, as the document you shared describes an application that publishes a message
carapace 7y ago
Yeah, a "Related Work" section would (potentially) be very reassuring. What would be really cool is if this could serve as a front-end to e.g. SPIN model checker ( https://en.wikipedia.org/wiki/SPIN_model_checker https://en.wikipedia.org/wiki/SPIN_model_checker https://en.wikipedia.org/wiki/Promela https://en.wikipedia.org/wiki/Promela )

jsdalton 7y ago

There appears to be far more details on the main website: https://www.asyncapi.com/ https://www.asyncapi.com/ Not sure why the Github repo was submitted.

augusto-moura 7y ago
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
- verdverm 7y ago
  I'd like to see an example on either landing point, both preferably.

makstaks 7y ago

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. edit: typo

MuffinFlavored 7y ago
I don't quite get it. Why can't I just enforce schema validation in my pub/sub handlers? I see the YAML example completed here: https://www.asyncapi.com/docs/getting-started/servers/ https://www.asyncapi.com/docs/getting-started/servers/ asyncapi: 2.0.0 info: title: Hello world application version: '0.1.0' servers: production: url: broker.mycompany.com protocol: amqp description: This is "My Company" broker. channels: hello: publish: message: payload: type: string pattern: '^hello .+$' This looks like a thin wrapper around sending a message to a message queue. What's the gain? Where do you define what to do as a subscriber?
- derberg 7y ago
  you have 2 operations in the spec, publish and subscribe. above example already tells you what to do as a subscriber, as the document you shared describes an application that publishes a message

carapace 7y ago

Yeah, a "Related Work" section would (potentially) be very reassuring. What would be really cool is if this could serve as a front-end to e.g. SPIN model checker ( https://en.wikipedia.org/wiki/SPIN_model_checker https://en.wikipedia.org/wiki/SPIN_model_checker https://en.wikipedia.org/wiki/Promela https://en.wikipedia.org/wiki/Promela )