Parse message `oneOf` as a single JSON Schema

[DavidBiesack]

Reason/Context

At present, the asyncapi-generator code necessary to handle oneOf in messages is cumbersome. See https://github.com/asyncapi/nodejs-template/issues/62 for example. The generator must check if the message schema is oneOf or not with

{% if channel.publish().hasMultipleMessages() %}

code blocks. Additionally the generator must generate code to validate the payload against each of the individual schemas. Thus, each generator must reproduce the behavior of a JSON schema validator.

Description

Enhance the parser and the associated operations such that it returns a consolidated JSON schema. If the message uses oneOf, return a JSON schema with oneOf construct. Thus, a generator merely has to get the message schema and validate it; it will work if the AsyncAPI uses oneOf or not.

At present, generators use

channel.publish().message(i).name() // if `oneOf` is used 
or
channel.publish().message.name() // if `oneOf` is not used

To avoid a breaking change, I suggest adding a new function to the parser which refers to the single combined message schema. I'm not sure how to express this, however.

[derberg]

I have to admit it is a nifty proposal, and I like it, I always struggled with oneOf on message level.

would it be a problem if channel.publish().message.name() work both with single or oneOf? just a thought 🤔

[DavidBiesack]

Ideally, for the long term evolution of AsyncAPI, I could get the combined schema via channel.publish().message.name() ; I'm just concerned about the impact - would that be a breaking change in the parser? I don't know the parser code well enough to decode it; there are not enough comments for me to understand the intent/use of message.name() / _json.name and AsyncApiValidator.fromSource.validate(messageName, payload, channelName, operation);

[jonaslagoni]

As mentioned in the SIG meeting, I see no reason why we cannot have something like a message.schema() (no idea what to call the function), that returns the combined payload schema with oneOf.

[derberg]

oh yeah, I don't like when naming gets more difficult than the actual implementation 😅

we have messages() that return all messages in an array, why not have maybe messagesSchema() with good jsDoc explaining it always returns all messages payload schema combined in one oneOf schema? 🤔

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

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 :heart:

[derberg]

• description of the issue is still accurate,
• goal is to add messagesSchema() to https://github.com/asyncapi/parser-js/blob/master/lib/models/operation.js and in case of this._json.message.oneOf, return all schemas/payload from all messages combined in single oneOf JSON Schema

Use case: https://github.com/asyncapi/nodejs-template/issues/62

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

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 :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

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 :heart:

[magicmatatjahu]

In version 2.x (in the Intent API) we don't have such a method, but I don't know if we should add such a thing. Any ideas? @derberg @jonaslagoni

[derberg]

I definitely recommend having it. David created this issue basing on the requirement from one of PRs he contributed to nodejs-template. This requirement makes sense from the point of view of the idea of intend-driven-api. Having a helper that returns all messages as oneOf will make it easier in code to have message validation in the application runtime

[magicmatatjahu]

But to clarify, oneOf of schemas, not messages. In v2 we return (even single message) as oneOf messages.

[derberg]

yup, have a look at https://github.com/asyncapi/parser-js/issues/372#issuecomment-1097651899

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

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 :heart: