Skip to content
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

Merged
merged 4 commits into from
May 6, 2022

Conversation

magicmatatjahu
Copy link
Member

@magicmatatjahu magicmatatjahu commented May 4, 2022

Description

  • port Message, MessageTrait, Operation, OperationTrait, CorrelationId and SecurityRequirements models
  • add unit tests

Related issue(s)
Part of #481
Part of #482

cc @smoya @Souvikns

Copy link
Member

@jonaslagoni jonaslagoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

@Souvikns Souvikns left a 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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hasSchema(): boolean;
schema(): SchemaInterface | undefined;
hasLocation(): boolean;
location(): string | undefined;
Copy link
Member

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

Copy link
Member Author

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 😄

Copy link
Member

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 {
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue :) #544

export interface OperationTraitInterface extends BaseModel {}
export interface OperationTraitInterface extends BaseModel, BindingsMixinInterface, DescriptionMixinInterface, ExtensionsMixinInterface, ExternalDocumentationMixinInterface, TagsMixinInterface {
id(): string;
kind(): OperationKind;
Copy link
Member

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

Copy link
Member

@smoya smoya May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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?

Copy link
Member

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noice!!! 👍

Copy link
Member Author

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?

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a TODO?

Copy link
Member Author

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.

Copy link
Member

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> }> ?

Copy link
Member Author

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> }>>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think makes sense

Copy link
Member

@smoya smoya left a 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

@sonarcloud
Copy link

sonarcloud bot commented May 5, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@magicmatatjahu
Copy link
Member Author

magicmatatjahu commented May 5, 2022

@smoya I propagated suggestions from your review. I didn't add uid and stay with id and messageId. I think that now it's good approach, we can always change it when we will see how 3.0.0 will look like.

I also updated parser-api asyncapi/parser-api#64

Copy link
Member

@smoya smoya left a 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...

@magicmatatjahu
Copy link
Member Author

/rtm

@asyncapi-bot asyncapi-bot merged commit f70b5c0 into asyncapi:next-major May 6, 2022
@magicmatatjahu magicmatatjahu deleted the next/message-model branch May 6, 2022 07:59
@magicmatatjahu magicmatatjahu mentioned this pull request May 19, 2022
20 tasks
magicmatatjahu added a commit to magicmatatjahu/parser-js that referenced this pull request Oct 3, 2022
derberg pushed a commit that referenced this pull request Oct 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request ready-to-merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants