Make `channels` field optional within an AsyncAPI file.

[smoya]

Context

This is part of the RFC https://github.com/asyncapi/spec/issues/618#issuecomment-980093487. In an effort around reducing the scope of such RFC, it has been split into several proposals so they can move forward independently.

The problem

From https://github.com/asyncapi/spec/issues/628#issuecomment-968050476:

One way we have seen the specification being used is in a Dictionary type of AsyncAPI document, which is a type of pattern for defining definitions for the common information, shared by each separate application.

However, users have been forced to declare an empty object as a value for the channels field since this is not optional.

Suggestion

To make channels field optional. It depends on https://github.com/asyncapi/spec/issues/660, because without it perhaps it won't make a lot of sense.

[derberg]

I think this one is pretty easy to push for January 2022 release. Change is small, and I know people use AsyncAPI just to list messages in components, and they do not need channels object and just leave it empty.

@Fannon not sure if you are the one that uses AsyncAPI this way or someone else from SAP? don't remember 😅

[Fannon]

@derberg : What do you mean with "this way" excactly? In the case of using CloudEvents, having channels with topic names may not bean ideal fit because with CloudEvents you would subscribe via "type" or "source" properties. A topic / channel then becomes an implementation detail or may not fit very well.

However, channels still make sense to indicate which events from messages are actually subscribable / actively sent (as opposed to events which are technically supported, but not "active").

If you need any more background, I can get in contact with my colleagues. I'm not working on this directory, but I'm in contact with the colleagues who do.

[derberg]

oh sorry, so I meant that someone from SAP uses AsyncAPI in a way that channels are just channels: {} and then just messages are listed in components. But yeah, I forgot how big SAP is and that probably it was someone not related to the work that you are doing 😆

this is the case I was talking about https://github.com/asyncapi/parser-js/issues/210

[smoya]

PR's have been created:

• https://github.com/asyncapi/spec/pull/682
• https://github.com/asyncapi/spec-json-schemas/pull/146

[smoya]

As per asyncapi/spec-json-schemas#146 (comment), we won't include this change in 2.3.0 but rather in 3.0.0.

[github-actions[bot]]

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

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 :heart:

[jonaslagoni]

I think we can close this one as it was introduced in https://github.com/asyncapi/spec/pull/827, or do we wait for implementation as well?

cc @derberg @fmvilas @dalelane

[fmvilas]

Moving to RFC 1. It's still missing JSON Schema and Parser implementations. I'll update the label once it's ready.

I know an RFC 1 should be a pull request but I think we can just make an exception here for now.

[github-actions[bot]]

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

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 :heart:

[smoya]

This issue is still relevant. Should be marked as completed once AsyncAPI v3 gets released.

[github-actions[bot]]

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

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 :heart:

[smoya]

https://github.com/asyncapi/spec/issues/661#issuecomment-1509415056