Address perspective and channel reuse issues through introducing 'endpoint' concept

[jessemenning]

2021.08.09 - Tried to create a non recursive definition of endpoint.

Summary

Issue

The AsyncAPI community acknowledges that there are significant issues related to the understandability of the spec for new users, the flexibility to address various async topologies and the reuse of channels across multiple applications.

Proposed Resolution

To address these issues, the proposal allows:

• Decoupling channels from applications and implementation details. Channels instead exist as a decoupled, logical means of exchanging messages.
• Explicitly describing the operations of all entities within an async topology

Result

The proposal gives users the ability within AsyncAPI to describe how:

• an endpoint does interact with logical channel(s)
• an endpoint may interact with one application
• a class of endpoints may interact with logical channel(s)

Technical Summary

The proposal introduces a top-level endpoint entity to AsyncAPI, and relaxes restrictions on mandatory AsyncAPI properties and entities. In order to ensure consistent tooling behavior in the face of this new flexibility, it also introduces several business rules.

General Discussion

In v2.1 an AsyncAPI spec "MUST describe the operations an application accepts." Stated another way, an AsyncAPI v2.1 spec describes how an endpoint may interact with a single application. When used for code generation, the single application is assumed to implement the inverse of what is described in the spec. In other words, if interacting endpoints can subscribe from named application, the spec assumes that named application publishes those messages.

For many use cases this is sufficient. This tends to true with users that are familiar with OpenAPI and implementing asynchronous client-server interaction.

However, as noted in the perspective issue, the mental gymnastics of "inverse implementation" remain a challenge for both new and experienced users, particularly in the context of code generation.

Additionally, AsyncAPI struggles to capture some async topologies. For instance, broker-mediated topologies are not exclusively (or even predominantly) one-to-one interaction. In fact, async architectures that use event brokers are typically a network of decoupled nodes interacting in complex ways. Here the assumption of inverse relationships fails, as components can:

• Interact in a one-to-many-fashion, serving as information provider to multiple components, while simultaneously serving as information consumer from multiple components.
• Selectively choose which events to receive from information providers
• Reuse an existing channel, either sending additional messages into the channel, or retrieving messages from the channel.

Discussion of Specific Proposed Changes

Address additional use cases and issues by allowing explicit Endpoints

☐ Introduce a top-level endpoint entity to AsyncAPI.

An endpoint is entity that sends, receives, or sends and receives messages via a channel. In AsyncAPI, an endpoint object represents either the implementation of a single endpoint, or a defines the capabilities of a generic class of endpoint.

In AsyncAPI an endpoint explicitly defines, from the perspective of the endpoint:

• What operation(s) does/can the endpoint implement?
  • Using a reference, what channels does the endpoint interact with?
  • How does this endpoint interact with the channel? Does it send data to the channel? Does it receive data from the channel? Or both?
• Optionally, for each operation, which endpoint-specific protocol bindings are present?
  • If sending messages to the channel, then what is the address (e.g. Kafka topic)
  • If receiving data from the channel, the what is the address (e.g. IBM MQ queue name)

The resulting AsyncAPI structure looks like:

The introduction of endpoint and the resulting loose coupling addresses both the perspective and the channel reuse issue. Because endpoints are defined from their own perspective, using intuitive verbs, the new user experience improves and code generation becomes less problematic. And by decoupling endpoints from channels by using references, channels can be reused by multiple endpoints.

Further Abstract Channel by genericizing verbs

The existing verbs in v2.1 (publish and subscribe) are linked to the pub-sub model of async interaction. Queues, mailboxes, websocket endpoints all can serve as asynchronous channels, but do not require either publishing or subscribing.
This proposal

☐ Deprecates the subscribe verb, replaces with endpointSends.
☐ Deprecates the publish verb, replaces with endpointReceives

(During a transition period, tooling which reads AsyncAPI specs should continue to accept subscribe and publish. Tooling which writes AsyncAPI specs should be updated to use endpointSends and endpointReceives.)

This change further abstracts the base Channel concept away from any implementation choice. The implementation details can in turn be specified as bindings, either attached to the channel or the endpoint-operation, depending if they apply to the channel, or to an individual endpoint’s use of the channel.

On a practical level, further abstraction of Channel allows point-to-point asynchronous communication, either brokered or unbrokered, to be represented by Channels without bending the common definitions of "publish" and "subscribe". This in turn increases consistency across a wider range of interaction styles.

Emphasize multiple physical realizations of underlying logical model

In examples to follow, the endpoint, channel and message entities are frequently presented as separate files. However, this should not be taken as a requirement. In fact, the increased use of references allows for a wide range of implementation options including:

• Separating endpoints, channels and messages into separate files
• Combining all entities into a single file
• Dividing up entities by business domain
• Utilizing a schema registry or event management portal in lieu of files

To facilitate this flexibility, the proposal
☐ Makes optional all top level entities (info, servers, channels, endpoints, components) .

The spec is unopinionated on what the best way to organize, govern, persist or access AsyncAPI. In fact, a single organization may use different physical AsyncAPI representations of the same underlying set of logical async interactions. And, depending on use case, an organization may choose to present only a piece of the overall architecture to an endpoint for reasons of security, simplicity, etc.

Differentiate Interface and Implementation when using endpoints

Currently AsyncAPI defines how a component MAY interact with the application. This reflects the intention of the document to serve as a true API, closely paralleling OpenAPI. For consistency and backwards compatibility, this will continue to be the assumption in the absence of explicitly defined endpoints.

That said, a separate and legitimate use of AsyncAPI is generating and documenting a particular endpoint’s implementation. OpenAPI (and REST) is tightly coupled to the HTTP/S protocol, so that verbs, URL, etc. can be assumed to be implemented using HTTP/S. In contrast, the asynchronous world uses a wide variety of protocols. Evidence of this is seen by provision of the specific binding information present in many AsyncAPI files and the growing number of code generation options. The need to explicitly provide implementation information in the asynchronous world forces a more explicit spec that allows for implementation details to be recorded in a systematic way.
To accommodate this reality, this proposal:

☐ Adds an optional field called intent to endpoint with allowed values interface and implementation
☐ Adds an optional field called required to operations, with allowed values true and false

intent indicates whether the purpose of this endpoint definition is an interface (defines a of class of endpoint) or the implementation of a particular endpoint.

For an interface endpoint, operations marked as required:true must be present in implementations of that interface. For example, if there is a an interface called StreetLight with a required operation, then an implementation of that interface (StreetLightAt123MainStreet), must implement that operation.

☐ Adds the following business rules:

If the intent is implementation, it is assumed that the endpoint definition describes an implemented instance of the endpoint. Thus all operations present in the file will be assumed to be implemented.

If the intent is interface, it is assumed to be an interface, describing possible operations that the endpoint MAY implement.
The default value of intent is interface, in keeping with v2.1 spec's view of the world.

If the endpoint is an interface, endpoints which implement the interface MUST implement the operation.

The default value of required is false (not required)

Clarify Inheritance rules when using references

To achieve decoupling and reuse, the proposed spec relies heavily on references from one entity to another. This (and the introduction of separate implementation and interface concepts) forces the spec to formalize the requirements with regards to inheritance when referencing another entity.

☐ Adds the following business rules:

In the case where Entity A references another entity B (e.g. another endpoint, channel, message), Entity A MUST inherit all the properties of Entity B (and likewise all the Entities that have been previously referenced). Entity A MAY modify a property of Entity B (and previously referenced entities) IF AND ONLY IF ONE OR MORE OF THESE CONDITIONS ARE TRUE:

• Endpoints may choose exclude optional operations (those not marked as required:true)
• There are parameters within the property (e.g. parameterized topic string). If parameter is restricted via type, enumeration or pattern, Entity A MUST follow the restrictions.

Summary of Proposed Changes

All changes are non-breaking.

☐ Deprecate publish in favor of endpointSends

☐ Deprecate subscribe in favor of endpointReceives

☐ Introduce endpoints entity to allow explicit definition of endpoints, including whether the endpoint represents an interface or an implementation

☐ Allow for messages to be associated directly with channels

☐ Make all top level entities optional

☐ Make verbs within the channel definition optional.

These changes evolve AsyncAPI towards more robust enterprise functionality and resolve lingering issues that could prevent wider adoption.

Specific Examples

WORK IN PROGRESS

To establish a common frame of reference, the following examples use the Streetlights tutorial from AsyncAPI.com as a baseline. As described in the tutorial, the company is called "Smarty Lighting and you do smart-city lighting systems". To better explain the proposal's implications, each example adds additional complexity to the baseline tutorial.

As-is Streetlights with AsyncAPI v2 Implicit endpoint

Demonstrates: Backwards compatibility with existing AsyncAPI specs
Adds to Streetlights: Nothing

The baseline Streetlights tutorial describes the API of a Message Broker.

The AsyncAPI v2.1 representation of the Streetlights is:

Streetlight API

channels:
  light/measured:
    publish:
      summary: Inform about environmental lighting conditions for a particular streetlight.
      operationId: onLightMeasured
      message:
        name: LightMeasured
		<<details omittted>>

As there are no explicit endpoints, it is assumed the API describes:

• how an implicit endpoint may interact with one endpoint

So, the implicit clients may choose to send LightMeasured events to the event broker.

It's important to note this would be valid AsyncAPI file in both v2 and v3. Tooling would continue to read the "publish" and "subscribe" verbs, although it would be expected that new versions of tooling would write "endpointSends" and "endpointReceives"

Here we can see the two issues:

• Perspective issue: AsyncAPI code generators create an application that subscribes to the events. This has proven to be difficult to explain to both new and existing users.

• Channel reuse: the light/measured channel definition is tightly coupled to the application and to the pub-sub architecture. If another application wishes to use light/measured, it would need to be included in its own AsyncAPI definition.

Explicit endpoints (AsyncAPI v3 style)

Demonstrates: More explicit definitions of actors could be beneficial in some situations
Adds to Streetlights: Conversion to AsyncAPI v3

In proposed v3 it becomes possible--though not mandatory--to explicitly create endpoints and/or classes of endpoints. The same Streetlights example becomes:

endpoint_streetlight.yaml

endpoint:
	StreetLight:
		endpointSends:  
			light/measured
				$ref: /uri/channels/light/measured

channels.yaml

channel:
	light/measured:
			message:
				name: LightMeasured	

As there are explicit endpoints, it is assumed the API describes:

• how an explicit endpoint can interact with one to many logical channels

The potential benefits of using the v3 approach?

• Perspective issue is less of a challenge. When applying a code generator, it is clear that the StreetLight sends LightMeasured events

Channel reuse

Demonstrates: Increased ability to reuse channels
Adds to Streetlights: Additional endpoints and channels

In proposed v3 it becomes possible--though not mandatory--to explicitly create endpoints and/or classes of endpoints. As endpoints interact in increasingly complex ways, decoupling the endpoints from channels increases reuse.

To demonstrate, this example adds a Control Hub endpoint, which receives light measurements from the streetlight. In turn, it sends out commands which can turn the streetlight on. Control Hub and Streetlight both reuse the same two channels.

endpoint_streetlight.yaml

endpoint:
	StreetLight:
		endpointSends:  
			light/measured
				$ref: /uri/channels/light/measured
		endpointReceives:  
			control/lightOn
				$ref: /uri/channels/control/lightOn

endpoint_controlhub.yaml

endpoint:
	ControlHub:
		endpointSends:  
			control/lightOn
				$ref: /uri/channels/control/lightOn
		endpointReceives:  
			light/measured
				$ref: /uri/channels/light/measured

channels.yaml

channel:
	light/measured:
			message:
				name: LightMeasured	
	control/lightOn:
			message:
				name: LightControl	

The potential benefits of using the v3 approach?

• Channel reuse: as the streetlight references the channel, rather than having a separate copy in each of their AsyncAPI specs, it can be reused by new endpoints. (Note, that although the channels here are persisted in a file, they could instead be defined in a common file in GitHub, a database, a repository or other store.)

Use of Interface/Implementation and required tags

Demonstrates: Additional possible interpretations of AsyncAPI
Adds to Streetlights: Additional streetlights, including some of which are external to the organization and describe implementations.

As event APIs become more sophisticated, there is an increased need for flexibility of inpretations and enterprise functionality.

In this example, the Streetlight API is provided to outside organizations. Streetlight owners can graciously crowd source their light measurements by sending them to Control Hub. However, external organizations do not need to receive Control Hub lightOn events.

To emphasize this, the intent of interface_streetlight.yaml is set to interface. And while the light/measured operation is marked as required:true, the control/lightOn operation remains optional (the default value).

In contrast the implementation (endpoint_streetlight_833Sparrow.yaml) is set to intent:implementation.

endpoint_streetlight_833Sparrow.yaml

endpoint:
	StreetLight833Sparrow:
		intent:implementation
		$ref: /uri/endpoints/StreetLight
		endpointSends
			light/measured

interface_streetlight.yaml

endpoint:
	StreetLight:
		intent:interface
		endpointSends:  
			light/measured
				required:true
				$ref: /uri/channels/light/measured
		endpointReceives:  
			control/lightOn
				$ref: /uri/channels/control/lightOn

endpoint_controlhub.yaml

endpoint:
	ControlHub:
		intent:implementation
		endpointSends:  
			control/lightOn
				$ref: /uri/channels/control/lightOn
		endpointReceives:  
			light/measured
				$ref: /uri/channels/light/measured

channels.yaml

channel:
	light/measured:
			message:
				name: LightMeasured	
	control/lightOn:
			message:
				name: LightControl	

Here, the third possible intpretation of AsyncAPI is shown:

• how an explicit endpoint does interact with one to many logical channels

In addition, enterprises can advertise their evented API products while clearly showing the functionality that the external API can and must provide.

Use of inheritance to specify which schema an endpoint uses amongst many in a channel

Demonstrates: Inheritance and override logic
Adds to Streetlights: Multiple possible messages within in a channel

As applications evolve, they will introduce breaking changes in the messages that they send. These breaking changes can cause failures for downstream applications. This is particularly true in brokers such as Kafka, where topics persist messages indefinitely, so that there may be multiple version of a message (or multiple message types) on the topic.

The decoupling of endpoints from channels allows implementers multiple ways to address this issue.

Wild West

Channel does not specify associated messages. Instead, each endpoint specifies which message it sends. Implies a lack of central governance, which means that applications receiving messages must be ready to adjust to breaking changes.

endpoint_controlhub.yaml

endpoint:
	ControlHub:
		endpointReceives:  
			light/measured
				$ref: /uri/channels/light/measured
					message:
						$ref: '/uri/components/messages/LightMeasuredv1'
		endpointSends:  
			control/lightOn
				$ref: /uri/channels/control/lightOn
					message:
						$ref: '/uri/components/messages/LightOnv1'

channels.yaml

channel:
	light/measured:
	control/lightOn:

Channel centric

Each channel specifies a single associated message, or a list of associated messages using oneOf. In turn, each endpoint specifies which message it sends and/or receives. If a channel contains a list of associated messsages, endpoints must select an option from that list . This topology likely implies some sort of central governance or tooling of shared channels, as applications must modify both their own AsyncAPI spec and that of the shared channel(s).

endpoint_controlhub.yaml

endpoint:
	ControlHub:
		endpointReceives:  
			light/measured
				$ref: /uri/channels/light/measured
		endpointSends:  
			control/lightOn
				$ref: /uri/channels/control/lightOn
					message:
						$ref: '/uri/components/messages/LightOnv2'

channels.yaml

channel:
	light/measured:
			message:
				oneOf:
					- $ref: '/uri/components/messages/LightMeasuredv1'
	control/lightOn:
			message:
				oneOf:
					- $ref: '/uri/components/messages/LightOnv1'
					- $ref: '/uri/components/messages/LightOnv2'

Defer to schema registry

Lastly, enterprises could defer schema management to a schema registry. Rather than list specific versions, references point to a schema registry, which can be used at either code-time, compile-time or run-time.

endpoint_controlhub.yaml

endpoint:
	ControlHub:
		endpointReceives:  
			light/measured
				$ref: /uri/channels/light/measured
		endpointSends:  
			control/lightOn
				$ref: /uri/channels/control/lightOn

channels.yaml

channel:
	light/measured:
			message:
				$ref: 'http://schemaregistry.com/components/messages/LightMeasured#latest'
	control/lightOn:
			message:
				$ref: 'http://schemaregistry.com/components/messages/LightOn#latest'

Use of Interfaces for external API products

Forthcoming

Specifying Binding details.

Under this proposal, channels become much more logical. Channels know only the following

• Message can be sent to the input of a channel
• Messages can be received from the output of a channel
• The channel is addressable
• As a dumb pipe, messages entering the channel are the same as messages exiting the channel (@jhigginbotham and I disagree on this one)

Optionally, and to align with the schema registry use case, AsyncAPI allows channels to know

• the message format(s) allowed within the channel

Making channels logical objects defers implementation details to protocol-specific bindings. This compartmentalizes implementation details, which has several nice properties:

• Workarounds, like the unofficial AsyncAPI vocabulary translator for WebSocket users should become less needed, as protocols bindings can be individualized without translating what "publish" and "subscribe" mean in a particular context.
• Swapping out implementations, like switching from Kafka to RabbitMQ or vice versa, don't mean changing the logical structure of your enterprise, just the physical bindings.

Symmetrical bindings- Input binding same as output binding
The simplest case is one in which the input binding will always be the same as the output binding. This is the case in Kafka. Endpoints sending data use the same topic as endpoints receiving data. In this case, existing bindings should work and should be at the channel level.

channel:
	light/measured:
			message:
				oneOf:
					- $ref: '/uri/components/messages/LightMeasuredv1'
					- $ref: '/uri/components/messages/LightMeasuredv2'
			bindings:
				kafka:
					groupId:
						type: string
						enum: ['myGroupId']
					clientId:
						type: string
						enum: ['myClientId']
					bindingVersion: '0.1.0'
	control/lightOn:
			message:
				$ref: '/uri/components/messages/LightOnv1'

Asymmetrical bindings- Input binding different than output binding
This needs more work, and I would love input from @nictownsend, @dalelane, @jhigginbotham and @damaru-inc on this.

On the other hand, several async protocols can have asymmetric channels, where input and output bindings are are not the same (e.g. AMQP topic to queue, IBM MQ queue to topic, Solace SMF topic to queue). To accommodate these use cases, the spec needs to have the ability to specify different channel input and output bindings.

Ideally, to keep the channel as logical as possible, the channel object itself would not know if it's symmetrical or asymmetrical. That implementation detail would be left to the binding.

The question is where asymmetric bindings belong. Thinking about things, there seem to be multiple possibilities:

• The binding at that point belongs to a specific action, either sending data to the channel, or receiving data from the channel. As such it should be housed under the endpoint-operation. But that is tough for channel registries, because if you are discovering a channel you don't really know how to connect to the channel.

endpoint:
	ControlHub:
		endpointReceives:  
			light/measured
				$ref: /uri/channels/light/measured
					ibmmq:				
						destinationType: queue
						queue:
							objectName: myQueueName
		endpointSends:  
			control/lightOn
				$ref: /uri/channels/control/lightOn
				bindings:				
					ibmmq:				
						destinationType: topic
						topic:
							objectName: myTopicName

• The bindings belong at the channel, with input and output stanzas, since they are really how the channel is implemented. This is the option that appeals to me the most, but I'm not sure how it would work with backwards compatibility.

channel:
	light/measured:
			message:
				oneOf:
					- $ref: '/uri/components/messages/LightMeasuredv1'
					- $ref: '/uri/components/messages/LightMeasuredv2'
			bindings:		
				ibmmq:
					input:				
						destinationType: topic
						topic:
							objectName: myTopicName
					output:
						destinationType: queue
						queue:
							objectName: myTopicName						
					bindingVersion: 0.1.0

Async Request/Reply (Websockets, NATS)
In general, these can be described as two different channels. Modifying the @derberg example:

endpoint:
	KrakenServer:
		intent:implementation
		endpointReceives:  
			krakenCommands
				$ref: /uri/channels/krakenCommands
		endpointSends:  
			krakenResponses
				$ref: /uri/channels/krakenResponses

endpoint:
	KrakenClient:
		intent:interface
		endpointSends:  
			krakenCommands
				$ref: /uri/channels/krakenCommands
		endpointReceives:  
			krakenResponses
				$ref: /uri/channels/krakenResponses
				
channels:
  /:
    krakenCommands:
      operationId: krakenCommands
      message:
        oneOf:
          - $ref: '#/components/messages/ping'
          - $ref: '#/components/messages/subscribe'
          - $ref: '#/components/messages/unsubscribe'
    krakenResponses:
      operationId: krakenResponses
      message:
        oneOf:
          - $ref: '#/components/messages/pong'
          - $ref: '#/components/messages/heartbeat'
          - $ref: '#/components/messages/systemStatus'
          - $ref: '#/components/messages/subscriptionStatus'	

References to servers from bindings

Forthcoming

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[fmvilas]

Love how much effort you've put into this proposal 👏 ❤️

I have a few comments/questions:

1. I don't really get what's an endpoint. Is it a node in the architecture? In the definition of "endpoint", you use "endpoint" as part of the definition and that got me lost 😅 It says: "An endpoint represents either the implementation of a single endpoint, or a defines the capabilities of a generic class of endpoint." Recursion alert 🚨 😄
2. I love the effort you've put into making it backward compatible. IMHO, we should get rid of whatever is making the spec inconsistent so we don't carry this pain forward. We'll keep supporting v2 for some years so that's not a problem. If someone wants to stay on v2 they can.
3. Unless I'm missing something, I think this thing about the intent:implementation or intent:interface is just going to make things more complex for no reason. This may be related to point 2 above though.
4. I love that you've solved the channel reuse problem at the same time. I think this is key.
5. I love that you can override a channel's message from within the endpoint's operation. Even though it's "wild west" 😄 it's super useful in some cases.
6. Lots of your examples are not viable because you're combining $ref with other stuff (e.g., intents example) or making the $ref line the parent of something else (e.g., wild west example). $ref has a special meaning and it can be dereferenced (e.g., replaced by the referenced object) at any time. Having attributes at the same level is not allowed and those libraries allowing you to do that are combining the referenced object with the additional attributes. That would result in invalid referenced objects.

I wonder how you would have modeled this proposal if you remove the backward-compatibility constraint. I challenge you to reimagine it 😄

[jessemenning]

@fmvilas awesome feedback, thank you. On point 6, I see what you mean. I'm not as good at JSON as I should be. Could we do something similar to OpenAPI spec:

components:
  schemas:
    Pet:
      type: object
      discriminator:
        propertyName: petType
      properties:
        name:
          type: string
        petType:
          type: string
      required:
      - name
      - petType
    Cat:  ## "Cat" will be used as the discriminator value
      description: A representation of a cat
      allOf:
      - $ref: '#/components/schemas/Pet'
      - type: object
        properties:
          huntingSkill:
            type: string
            description: The measured skill for hunting
            enum:
            - clueless
            - lazy
            - adventurous
            - aggressive
        required:
        - huntingSkill
    Dog:  ## "Dog" will be used as the discriminator value
      description: A representation of a dog
      allOf:
      - $ref: '#/components/schemas/Pet'
      - type: object
        properties:
          packSize:
            type: integer
            format: int32
            description: the size of the pack the dog is from
            default: 0
            minimum: 0
        required:
        - packSize

[fmvilas]

We're already doing that at Schema Object level (same as in OpenAPI). The Schema Object is a pure JSON Schema object, not something OpenAPI or AsyncAPI defines.

[derberg]

That was a long read! well done.
I think we should get rid of backward compatibility. Spec is not an API, we should just release new version and improve it best way we can to make sure others migrate + have as powerful converters as possible

[jonaslagoni]

@jessemenning I assume you want to champion this through? 🙂 Or can we consider this issue as needs champion? 🤔

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

@jessemenning do you want to drive it further?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️