-
-
Notifications
You must be signed in to change notification settings - Fork 281
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
[RFC] Support JSON Schema for bindings #507
Comments
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. |
At the moment bindings have versioning independent from spec version, and it is good imho. |
I agree with that! We can use for that standalone compilation to generate validation function for our schema to improve performance. At the moment we "compile" (including dereferencing) schema in each execution of the |
@magicmatatjahu are you talking about splitting the task of validating bindings into separate standalone components and only validate those bindings in use? Instead of everything at once? 🤔 |
@jonaslagoni No. Ajv supports compilation of the JSON Schema to "standalone" function which can be saved to file and then reused in JS application. In reference to @derberg comments:
So by this standalone function we can dereference refs for binding's JSON Schemas, compiled it and save to file and use this function in parser. By this operation we can move EDIT: Of course this logic doesn't handle the problem with JSON Schemas for extensions (also for custom bindings), but it is a good way to handle supported bindings and speed up the parser. |
I would not worry much about custom bindings, we accept any bindings in the spec, look at IBM or Anypoint (in progress). Json schema for extensions will be solved by extension registry. My feeling is this is not related to spec at all as json schema is a tool, not the spec. Next step would be to first create those JSON Schemas for bindings, right? the only open problem for me is location. Bindings repo seems best as it will be better to maintain it, but on the other hand, in the asyncapi json schema we should not reference files from |
I want to help implement this feature, As I understand we need to:
Sorry, these questions might have obvious answers that I don't see. |
yeap 😄 but don't worry, some do not have bindings defined yet.
This one is a next step after the previous one, like a final step on how to at the end enable parser to consume these schemas. Let's just solve it step by step I think and first figure out how and then create files with JSON schemas |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
Bindings schemas are already merged with asyncapi/bindings#60 |
This issue has been automatically marked as stale because it has not had recent activity 😴 |
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 ❤️ |
I think it makes sense to move this to https://github.com/asyncapi/spec-json-schemas, right? |
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 ❤️ |
@derberg Could you unstale that issue. We have discussed solution for it :) |
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 ❤️ |
@magicmatatjahu I suggest we close it
or we move it to |
Agree this can be closed :) |
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 ❤️ |
@derberg can you close this one as complete 🙂 |
closing as merge of asyncapi/spec-json-schemas#208 will solve it definitely |
Is your feature request related to a problem? Please describe.
Making review for this PR asyncapi/asyncapi-react#259 I realized that we don't have JSON Schema definitions for officially supported bindings by AsyncAPI. Currently we have only markdown documents like for
http
-> https://github.com/asyncapi/bindings/tree/master/httpWithout JSON Schema for bindings we cannot:
parser-js
,parser-js
,Can't it be tackled using specification extensions? and Describe the solution you'd like
We can use extensions to define JSON Schema for each officially supported bindings (link).
I very like this approach (treating bindings as extensions), because then versioning of bindings is not related to AsyncAPI versioning at all - bindings can be versioned next to the official AsyncAPI release without any problems.
Problems which I see with this solution:
bindings
repository is the best place.bindingsObject
object? Make references to external JSON Schemas inbindings
repo or maybe remove whole object and then user should define extension of appropriate binding in spec? TBH I don't know. In my PoV I would like to choose second variant, because I think that AsyncAPI JSON Schema should be as small as possible without reference to external sources, but it could degrade DX. Feel free to share your thoughts about that!Describe alternatives you've considered
If we cannot use extension to define JSON Schema for official supported bindings, then only solution as I see, is describing definition here, but I very don't like this.
The text was updated successfully, but these errors were encountered: