-
-
Notifications
You must be signed in to change notification settings - Fork 269
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
[FEATURE REQUEST] Relate channel parameter to payload field #199
Comments
This is a great idea. We can probably use Runtime Expressions as we did with Correlation IDs: https://github.com/asyncapi/asyncapi/blob/master/versions/next/asyncapi.md#correlationIdObject |
In case you use "context", "schema" is not needed because it will be taken directly from the definition of the payload field. Also, pointing to a payload field makes this field mandatory in the payload or we should provide a default value. |
I think mandatory is the best option, In my opinion there will be much cases where no default value exists the example above shows it good. if we subscribe or publish to a channel where a "userId" is a parameter a default value would be crazy :). But, in my experience there will be definitly cases where a default value makes sense. So why not both?
If a default value is provided it will be used if nothing was provided, if the default value definition does not exists, the parameter becomes mandatory, maybe but only maybe a definition of optional: true without a default value can make the parameter optional? |
Note to myself: check out #215 before starting to work on this issue. |
+1 using a runtime expression here would be a great idea. We're having similar discussion on runtime expressions for selecting entire payloads. Applying them to parameter extraction within a Channel key would be great. |
🎉 This issue has been resolved in version 1.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Is your feature request related to a problem? Please describe.
AsyncAPI 2.0.0/next version supports parameters in channel names which is great. But, there is no context as to where the value comes from. One of the things I see often is that the parameter is populated from the runtime event payload. If we supported noting this context, code generation could do this lifting and make the experience easier for developers.
Can't it be tackled using specification extensions?
The specification needs some sort of a context field that is optional.
Describe the solution you'd like
See below:
Describe alternatives you've considered
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: