-
-
Notifications
You must be signed in to change notification settings - Fork 280
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
Allow servers
and channels
to be defined inside components
#660
Comments
servers
and channels
to be defined inside components
I'm championing this one if no one is against it. |
I think you have to include part of #650 so that servers and channels can be referenced, otherwise there is no need to define it in components 🙂 |
Some work has been done now in order to properly illustrate the change. That doesn't mean this should be accepted.
|
I'm gonna ping some people I think might be interested in this. Please do not feel you have to review this, just to raise some awareness :) Thanks! cc @fmvilas @GeraldLoeffler @damaru-inc @jessemenning @magicmatatjahu |
Can we clarify that this is depending on #650? Otherwise, as Jonas said, it's useless, right? |
The current changes in both opened PRs (as per today) consider #650. For example, asyncapi/spec-json-schemas#133 adds |
Parser-JS PR is now a thing asyncapi/parser-js#430 🎉 |
my point of view here is that even if this would not be driven by the RFC about publish/subscribe, this PR would still make sense. Mainly because of Simplicity and consistency over expressiveness and terseness principle. In a single document, referencing server or channel to components doesn't make much sense, but we know that people do share data between asyncapi documents, just look at https://github.com/asyncapi/spec/tree/master/examples/social-media. So yeah, current problem is that you can reference server and need to duplicate it. And anyway for consistency I think it is good that all root objects can be in components. Imho this is a good candidate for stage 3, @fmvilas thoughts? |
I've been moving forward with this and, unfortunately, the only thing it can be moved to components is one of the servers. See the diff here. |
@fmvilas from my POV this one can be promoted to
any only one small thing must be clarified in the Parser-related PR and that is it. |
And just for keeping this issue up-to-date, the thing to be clarified on the Parser-js PR is done and waiting for approval. |
Yup, agree this can be promoted to stage 3. Approved the other PRs as well. Great stuff, @smoya! |
Context
This is part of the RFC #618 (comment).
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
Users can't define
servers
andchannels
as components. Meaning this has an impact on reusability.In the scenario of #654 and #658, reusing components is more than a requirement.
This will allow users to reference both
servers
andchannels
so the following will be now valid:Suggestion
To allow
servers
andchannels
to be defined insidecomponents
.As far as I see, this won't be considered as breaking change.
Depends on #650
The text was updated successfully, but these errors were encountered: