For async api first, if both producer and consumer need to write down their channel part for asyncapi docs? and why?

[max2liu]

For async api first, if both producer and consumer need to write down their channel information part for asyncapi docs? and why?

What I want to realize is the working flow of async api first, one opinion is that our approach is Event-Driven Architecture, so for the producer, it doesn't care and doesn't need to know who consume the event, so for the consumer, they do not need to write the asyncapi.

Any comments for above opinion?

---Quote the fields I mentioned above under the asyncapi docs---

subscribe : A definition of the SUBSCRIBE operation, which defines the messages produced by the application and sent to the channel.
publish : A definition of the PUBLISH operation, which defines the messages consumed by the application from the channel.

[derberg]

@max2liu I need a bit of clarification on what you mean.

I agree:

• yes, in EDA, producer do not need to know who consumes
• yes, in EDA, consumer do not need to know who produces

It really depends on your use case. You need to share more of your context. Depends what you want to use asyncapi.yml for, who is the target audience?

there are many different use cases, but just to give 2:

• server code generation -> then you write AsyncAPI for your app, so you can generate code for it
• sometimes consumers know who is a producer, they just need to know where it produces messages, so consumers need docs

[max2liu]

Hi @derberg , thanks for your reply, now let me supplement more about my use case:

say when there is person information updated, provider will send a PersonUpdatedEvent to related topic, now there is a consumer will register a queue and consume this message. below is the architecture diagram:

I wonder in this case, for the API first working flow, will the consumer need to write down the asyncapi.yml? if yes, how the working flow looks like? below is related yml context for reference:

Provider:

channels:
  'COMMON/-/G/CN/LEAVE_QUERY/PUB/EVT/PERSON_UPDATED/V01/Y/-':
    subscribe:
      operationId: sendPersonEvent
      description: 'send Person create or update Event'
      bindings:
        solace:
          bindingVersion: 0.3.0
          destinations:
            - destinationType: topic
              deliveryMode: persistent
      message:
        $ref: '#/components/messages/PersonMsg'

Consumer:

channels:
  'COMMON/CN/LEAVE_QUERY/PERSON_UPDATED/QUE':
    publish:  
      operationId: receivedPersonEvent
      description: 'receive Person updated Event'
      bindings:
        solace:
          bindingVersion: 0.3.0
          destinations:
            - destinationType: queue
              deliveryMode: persistent
              queue:
                name: UpdatedHREvents
                topicSubscriptions:
                  - COMMON/-/G/CN/LEAVE_QUERY/PUB/EVT/PERSON_UPDATED/V01/Y/-
                accessType: exclusive
                maxMsgSpoolSize: 1000MB
                maxTtl: 0s
      message:
        $ref: '#/components/messages/PersonMsg'