Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Converter cannot handle reusability #90

Open
Tracked by #110
jonaslagoni opened this issue Feb 4, 2022 · 5 comments
Open
Tracked by #110

Converter cannot handle reusability #90

jonaslagoni opened this issue Feb 4, 2022 · 5 comments
Labels
enhancement New feature or request keep-open

Comments

@jonaslagoni
Copy link
Sponsor Member

Reason/Context

If you want to do reusability in AsyncAPI, you cannot use the converter as it only changes the provided AsyncAPI file.

This renders the library more or less "useless" in those cases as we heavily encourage reuseability.

@jonaslagoni jonaslagoni added the enhancement New feature or request label Feb 4, 2022
@magicmatatjahu
Copy link
Member

@jonaslagoni HI! What do you mean for reusability? Do you mean that library doesn't move reusable parts to the components section or what?

@jonaslagoni
Copy link
Sponsor Member Author

@jonaslagoni HI! What do you mean for reusability? Do you mean that library doesn't move reusable parts to the components section or what?

No, what I mean is that if you split out your AsyncAPI document in any form, the converter does not traverse (to the best of it's ability) the external references.

Say you have a $ref such as this:

"$ref": "./messages/SomeMessage.json"

The converter won't access the local file and convert the message structure, only the main AsyncAPI document are converted 🙂

@magicmatatjahu
Copy link
Member

@jonaslagoni Good insight! But then people will have everything in single file, or we should just add to possibility to convert "chunks" of AsyncAPI? But then we need some logic for traversing $ref 😆 I wonder if it's a big problem, because only case when we need convert the external resources is situation with 1.X.X versions (and in the future 2.X.X -> 3.X.X).

@jonaslagoni
Copy link
Sponsor Member Author

@jonaslagoni Good insight! But then people will have everything in single file, or we should just add to possibility to convert "chunks" of AsyncAPI? But then we need some logic for traversing $ref 😆

Yep 😅

I wonder if it's a big problem, because only case when we need convert the external resources is situation with 1.X.X versions (and in the future 2.X.X -> 3.X.X).

Depends on what you define as a problem I guess. In my case, I would like to use the converter to automatically convert my documents on new AsyncAPI releases, so I don't have to do anything on my end to use the newest AsyncAPI version.

In many cases, only major versions would require to traverse documents yes (unless deprecated properties should be changed 🤔). However, as major versions can happen anytime, this feature would be greatly appreciated 🙂

@magicmatatjahu
Copy link
Member

@jonaslagoni

In many cases, only major versions would require to traverse documents yes (unless deprecated properties should be changed 🤔). However, as major versions can happen anytime, this feature would be greatly appreciated 🙂

Hmm, so I think that we should ship that issue for 3.X.X. Of course if people will raise that issue for 1.X.X conversion we should consider to implement it, but yeah, don't focus on something that people don't want and it useless (useless atm of course).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keep-open
Projects
None yet
Development

No branches or pull requests

2 participants