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

Make Server Variables Object available as reusable objects under the Component object #707

Closed
Tracked by #735
danielkocot opened this issue Feb 5, 2022 · 9 comments
Labels
🏁 Accepted (RFC 3) RFC Stage 3 (See CONTRIBUTING.md)

Comments

@danielkocot
Copy link

Hello everybody,

it is just an idea that came to my mind when I started to write a new post about AsyncAPI in reference to the releases 2.2.0 and 2.3.0. In my example I'm using two servers description for staging and production. Both of them have the same variable in reference to the port of the server.
So I thought it would be good to make Server Variables Objects available as reusable objects under the Component Object.

But let's discuss about it.

Best,
Daniel

@danielkocot danielkocot added the 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) label Feb 5, 2022
@github-actions
Copy link

github-actions bot commented Feb 5, 2022

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.

@magicmatatjahu
Copy link
Member

@danielkocot Hi! We don't have Variable(s) Object but Variable Object, I think that you have in mind that second :)

However, a similar idea has been floating around in my head for a few days now 😅 You can define reusable Channel's Parameters in the Components Object, so you should be able to define Server Variable as well. However, I wonder if we can "unify" Server Variable and Channel Parameter to the one Spec Object and reuse it across Channels and Servers. I created some months ago similar issue #583 but related to the inconsistencies of schemas in server.variables and channel.parameters. Atm only problem I see is related to the location in the single Parameter Object, so we have to think how to handle that location because in Server Variable we don't have such a field. schema and description we can still unify, but not that location.

@danielkocot
Copy link
Author

danielkocot commented Feb 6, 2022

Yeah, @magicmatatjahu. You're right! Thanks for spotting me to the issue you created and I saw that it is set for the roadmap of the 3.0.0. release. Maybe we can work together on a pull request get the ideas we have in a more clear direction. What do you think?

@magicmatatjahu
Copy link
Member

Maybe we can work together on a pull request get the ideas we have in a more clear direction. What do you think?

We can, no problem :) Of course we can also go with direction that first we will add possibility to declare that Server Variable in the components section (in the 2.4.0 version of spec) and in the 3.0.0 we will introduce unified Spec Object for both Parameter and Server Variable :) Merge of Server Variable and Parameter will introduce braking change, so we need wait for that for 3.0.0.

For me, we can go with that new field in the components section and in next major version simplify it. cc @derberg @fmvilas @jonaslagoni @smoya

@fmvilas
Copy link
Member

fmvilas commented Feb 7, 2022

Yup, always in favor of more and better reusability 👍

@danielkocot
Copy link
Author

Related PR #717

@smoya
Copy link
Member

smoya commented Apr 19, 2022

@derberg derberg added 🏁 Accepted (RFC 3) RFC Stage 3 (See CONTRIBUTING.md) and removed 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) labels Apr 20, 2022
@derberg
Copy link
Member

derberg commented Apr 20, 2022

yup, all seems to be there, there is only a merge conflict in one of the PRs

@smoya
Copy link
Member

smoya commented Apr 27, 2022

This issue can be now closed as it got merged and released. @danielkocot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏁 Accepted (RFC 3) RFC Stage 3 (See CONTRIBUTING.md)
Projects
None yet
Development

No branches or pull requests

5 participants