[Feature Suggestion] Filter by usage

[smoya]

I suggest all methods on the root document such as root.channels(), root.operations(), root.messages(), etc return all objects from around the document (including those in components). On the contrary, as the perspective is always from the Application, those methods located in other places rather than the root will return objects associated with such collection; for example root.operations()[0].channels() will return channels associated with that particular operation.

In order to filter by objects in use or not in use by the Application, we could add .filterByInUse() and filterByNotInUse() methods to servers, channels and messages.

See the following examples:

• Channels from root:
  • root.channels().all() (method that already exists) -> returns channels across the whole document
  • root.channels().filterByInUse() -> returns channels used by the application
  • root.channels().filterByNotInUse() -> returns channels not used by the application
• Channels from components:
  • components.channels().all() (method that already exists) -> returns all channels defined as components.
  • components.channels().filterByInUse() -> returns channels used by the application
  • root.channels().filterByNotInUse() -> returns channels not used by the application
• Servers from channels defined in the application (not as components):
  • root.channels()[0].servers().all() (method that already exists) -> returns servers associated to a particular channel.
  • root.channels()[0].servers().filterByInUse() -> this will return the same as all() in this case.
  • root.channels()[0].servers().filterByNotInUse() -> this will return an empty array.

In terms of implementation (at least for Spec v2.x.x), we could compare the JSON payload to determine if an object is isolated only in components or used by the application.

The benefit I see is that this decouples even more the API from the document shape, as no matters where the objects are declared (components, root of the document, etc), we would now have standard methods to access those. That means if a BC is introduced within the spec where, i.e. channels are not defined anymore in the root document but somewhere else (like components), there will be no BC in the API.
Also the use case where some tooling needs to generate all models (like modelina) could benefit from this as well.

Originally posted by @smoya in asyncapi/parser-js#619 (comment)

cc @fmvilas @magicmatatjahu @jonaslagoni

[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 ❤️

[fmvilas]

Dear bot, don't close this issue. Sincerely, your human ❤️

[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 ❤️