Parse and validate bindings

[magicmatatjahu]

Reason/Context

Part of asyncapi/spec#507

Already we have defined JSON Schemas for official supported bindings in bindings repo by this PR. We should think how to handle validation of bindings in the parser side.

Some my insights and founded problems:

• we shouldn't write models/mixins (generally functions for retrieving data) for bindings due to generic character of bindings. We can think about it in the future, but not now. It's not important now.
• for binding dev/user can define version of binding so we cannot make reference to appropriate version of binding inside the official JSON Schema of spec, however, we should figure out a way to find out which version the user has used and validate the binding according to that version in parsing time, and how to "download" corresponding JSON schema.
• Nice to have, but not needed in first implementation: figure how to avoid unnecessary downloading the schemas of bindings in each validation/parsing of given AsyncAPI spec. Download the schemas in release step of parser-js or maybe make something like memo system inside parser? I don't know which will be better. Very important here is our react-component and in the future other front-end apps/libs. In the front-end side parser should be fast as possible and small so we cannot bundle every binding schemas inside parser package.

Part of asyncapi/spec#507
It's related to #50

[GeraldLoeffler]

A typical definition of bindingVersion in a bindings specification (say, for AMQP in https://github.com/asyncapi/bindings/tree/master/amqp#channel-binding-object) is: The version of this binding. If omitted, "latest" MUST be assumed.

So the parser must be able to

• retrieve the JSON schema for a given bindingVersion of a given binding (say AMQP)
• or, if no bindingVersion is given in the AsyncAPI doc, or if bindingVersion is given as latest, determine what the latest available version of that binding is, and retrieve the JSON schema for that binding,
• and then use that exact JSON schema for validation.

[magicmatatjahu]

@GeraldLoeffler Thanks for the input!

I forgot about latest, thanks! We should think of way how to have registry of bindings. Maybe save all bindings to @asyncapi/bindings package with structure (similar approach we have for @asyncapi/node package which will be renamed to @asyncapi/specs):

const bindings = {
  [bindingName]: {
    [version]: ...corresponding JSON Schema
  }
}

of course for that we should create script to push on every merge to bindings repo new version of package with latest and previous JSON Schema of bindings. We should also consider how we should attach given JSON Schema to version of binding. I think about git tags and using them, download all JSON Schema. Of course latest numeric tag for binding will be the latest version of binding.

[derberg]

Bindings are part of the spec, so should be part of https://www.npmjs.com/package/@asyncapi/specs. I don't think there is much to do in the parser itself. We just need a proper workflow on bindings repo that whenever we have changes in JSON Schemas, we push an update to https://github.com/asyncapi/asyncapi-node. "Push an update" I mean push updated JSON Schema to asyncapi-node, and original AsyncAPI JSON Schema file will have $ref to given binding as local file, we can even resolve it when publishing @asyncapi/specs package.

Why not much to do on the parser side? as once the linking between main schema and bindings are done, we get validation out of the box

[magicmatatjahu]

@derberg But if you bind latest version of binding inside the spec JSON Schema, how do you handle the other versions of bindings in validation?

[derberg]

we need to support all the versions, but still, better to do it in JSON Schema rather than the parser. Might be that to make things easier, we end up moving JSON Schemas of bindings to asyncapi-node, I'm not sure about that, did not dig the topic

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

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 ❤️

[github-actions]

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 ❤️

[github-actions]

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 ❤️

[github-actions]

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]

Still valid.

[github-actions]

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 ❤️