CloudEvents reference

Connectors & Integrations
4

Hey @rajeshdns,

Maybe an over simplification, but how I think of it is like this:

  1. AsyncAPI defines your app and the channels that events are exchanged on
  2. CloudEvents define the envelope which your event complies with; and offers the choice of “structured” or “binary” content modes. (Note, my default would be to go with binary mode if the eventing system you’re using supports headers - which most do, such as Solace, Kafka, AMQP, MQTT5, HTTP )

Given their different areas of focus I think the two specifications should actually be used together.

Here are two resources that might help for further learning and actually seeing them used together:

  1. Simulating CloudEvents with AsyncAPI and Microcks - specifically the “CloudEvents with AsyncAPI” section shows examples of both CloudEvents content modes.
  2. @JesseMenning wrote a blog: AsyncAPI, CloudEvents, OpenTelemetry: Which Event-Driven Specs Should Your DevOps Include which might help folks get a better understanding of where the specifications are focused.

Note that I could see a time in the not so distant future where you could choose an Event Type of CloudEvent in the Solace Event Portal, specify your chosen content mode and your event would be pre-populated with the required headers. Also when you export an AsyncAPI document defining this same app it would of course properly have your CloudEvents defined in AsyncAPI :wink: