-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
refactor: port message, operation, correlation-id and security-requirements models #542
refactor: port message, operation, correlation-id and security-requirements models #542
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't read all the files
export interface ChannelParameterInterface extends BaseModel {} | ||
export interface ChannelParameterInterface extends BaseModel, DescriptionMixinInterface, ExtensionsMixinInterface { | ||
id(): string; | ||
hasSchema(): boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this should stay, should be added to https://github.com/asyncapi/parser-api/blob/master/docs/v1.md#channelparameter
hasSchema(): boolean; | ||
schema(): SchemaInterface | undefined; | ||
hasLocation(): boolean; | ||
location(): string | undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as before, If this should stay, should be added to https://github.com/asyncapi/parser-api/blob/master/docs/v1.md#channelparameter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The channel parameter has a location so it has to stay 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind then creating a PR on Parser-API repo?
|
||
export interface MessageTraitInterface extends BaseModel {} | ||
export interface MessageTraitInterface extends BaseModel, BindingsMixinInterface, DescriptionMixinInterface, ExtensionsMixinInterface, ExternalDocumentationMixinInterface, TagsMixinInterface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some missing methods from the Parser-API that I think should be implemented here (otherwise, discarded from the Parser-API).
- hasKnownSchemaFormat() :
boolean
- schemaFormat() :
string
See https://github.com/asyncapi/parser-api/blob/master/docs/v1.md#message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't add it on purpose for a simple reason. Defining schemaFormat
at the messag level on a lot of problems from a schema reuse point of view, and I will try to move schemaFormat to the Schema object - then this will be removed. Here is my issue for 3.0.0 asyncapi/spec#622. If we want it I can add it, but I hope that in 99% we will remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense indeed. How would you implement that? I think this should be then done in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add schemaFormat
in this PR to Message
model, but we can always remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, makes sense.
I like the message.payload().schemaFormat()
you suggested in asyncapi/spec#622. Maybe we can move forward with it later on, and now just adding an issue to work on it next?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue :) #544
src/models/operation-trait.ts
Outdated
export interface OperationTraitInterface extends BaseModel {} | ||
export interface OperationTraitInterface extends BaseModel, BindingsMixinInterface, DescriptionMixinInterface, ExtensionsMixinInterface, ExternalDocumentationMixinInterface, TagsMixinInterface { | ||
id(): string; | ||
kind(): OperationKind; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be added into the Parser-API https://github.com/asyncapi/parser-api/blob/master/docs/v1.md#operation, as well as removing some of the methods related to Publish/Subscribe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, kind
VS type
. For example, in Security Schemes, we use type
https://github.com/asyncapi/parser-js/pull/542/files#diff-dfe2dcce2b8c529ef868faf21548e2ba16163b0c4b9ef33129ac286346f2e008R15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, we have inconsistencies. type
in SecurityRequirements and here kind
. In 3.0.0 we have for example called it as action
(asyncapi/spec#618) so maybe we should call it action
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, action
sounds like a better fit.
} | ||
|
||
id(): string { | ||
return this.messageId() || this._id; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noice!!! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I have a problem, because on one side we call it id
, and next to it we have messageId
. Maybe we should rename this method to uid
and for id
return the value for messageId
? Same for other objects - where we call the method id
we should call it uid
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The messageId
is the real unique id (uid) across the document, so I think it would be the other way around.
Anyway, I see the issue you are mentioning.
Maybe, adding a new UniqueIdentifiableInterface
, with the uid
method would make sense. In the case of message, to return this.messageId()
, this.operationId
for Operation, etc.
The id
field will then just return the key of the map which the object belongs to.
Makes sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense, but I wonder if we need 3 methods, messageId
, id
and uid
.
The id
could be for messageId
The uid
for the messageId
or key or some generated unique id for given reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are considering a different thing for what the id
value is.
From my pov, id
is just the key on the map. For example, myMessage
in the following example:
components:
messages:
myMessage:
# etc
Of course, currently messages declared inside the operation won't have an id (at least on spec v2.x) but this could change for next versions (and makes sense to me).
|
||
export class SecurityRequirements extends Collection<SecurityRequirementInterface> implements SecurityRequirementsInterface { | ||
override get(id: string): SecurityRequirementInterface | undefined { | ||
// return this.collections.find(trait => trait.id() === id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a TODO?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and no. Because of the fact that these objects do not have id
I wonder if we should return undefined
, or change this collection to a regular array and not collection class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Can't we do just directly use Record<string, { schema: SecuritySchemeInterface, scopes: Array<string> }>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cannot, security
field (in security and operation) is an array, so we ca change it to the
Array<Record<string, { schema: SecuritySchemeInterface, scopes: Array<string> }>>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mainly looks good to me! 🎉 Left some comments and suggestions
Kudos, SonarCloud Quality Gate passed! |
@smoya I propagated suggestions from your review. I didn't add I also updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super great work @magicmatatjahu! 🚀 🌔 I approve it but I'm not code owner so...
/rtm |
Description
Message
,MessageTrait
,Operation
,OperationTrait
,CorrelationId
andSecurityRequirements
modelsRelated issue(s)
Part of #481
Part of #482
cc @smoya @Souvikns