Integrate modelina to generate models

[jonaslagoni]

Reason/Context

Sometimes you just want to generate the data models for the payloads in your AsyncAPI file, therefore I would like to integrate Modelina with the CLI, so we can offer an easy way for users to generate them.

Description

As a start, I would like to integrate it with no customization, at least for now, so you can only select the output language and nothing more.

But which format of commands is best fitting?

I think something like the following should be fine: asyncapi generate models --language=ts

[github-actions]

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.

[boyney123]

@jonaslagoni like the idea!

How will it know which file to use?

[jonaslagoni]

Without knowing any depth of the implementation from a CLI side of things, I assumed you would use the context?

Or would it need to use something like asyncapi generate models --file=./myfile.yaml --language=ts? 🤔

[jonaslagoni]

Also, one point to consider, since Modelina, don't only support AsyncAPI documents as inputs, I guess through the CLI it should be possible to provide other input types as well, or?🤔

[boyney123]

Also, one point to consider, since Modelina, don't only support AsyncAPI documents as inputs, I guess through the CLI it should be possible to provide other input types as well, or?

I'm not sure, where do the boundaries start and stop. Given it's the asyncapi cli, I think it should just handle the related inputs personally (asyncapi files) or at least to start?

[jonaslagoni]

I'm not sure, where do the boundaries start and stop. Given it's the asyncapi cli, I think it should just handle the related inputs personally (asyncapi files) or at least to start?

Yea, I agree. Lets just focus on AsyncAPI files and see where it goes 👍

[derberg]

are you sure about models here asyncapi generate models? what about generator itself, how would it be called? asyncapi generate template? -> I'm afraid user experience depends on how underlying libraries are structured

shouldn't it be asyncapi generate filepath/contextname model/template --parameters/--options ?

[jonaslagoni]

shouldn't it be asyncapi generate filepath/contextname model/template --parameters/--options ?

Can you elaborate on how you see the difference between the generator and Modelina?

Do you mean in terms of generation we could do this:
Generator: asyncapi generate filepath/contextname @asyncapi/template --parameters="something"
Modelina: asyncapi generate filepath/contextname model --language=typescript

[derberg]

except of @asyncapi/template is just confusing 🤔 as it is not a command :( it is an argument that might be different depending on what template you want to use. Also template cannot be a flag as options should not be mandatory 🤔

Have a look at #143 and another use case for asyncapi generate

[derberg]

how about (especially looking at the PR mentioned above by @fmvilas that relates to @arjungarg07 work):

asyncapi generate diagram --type='plantuml'
asyncapi generate docs --type='html'
asyncapi generate types --language='typescript'
asyncapi generate app --type='nodejs'

thoughts? who cares about the dependencies, in which command what tool is used, cupid or modelina?

we would only need to leave the gate open for folks with custom templates 🤔

asyncapi generate fromTemplate --template='@asyncapi/java-spring-template'

[jonaslagoni]

I think that makes sense! Even if we change it later it should not be a problem, we just need to start with something that makes sense 😄

[magicmatatjahu]

Solution that we should consider for that issue asyncapi/community#249 It's only an idea so please treat it as suggestion, not final approach. Feel free to comment :)

[fmvilas]

I'm happy to be a mentor for this issue in the Mentorship program.

[peter-rr]

@fmvilas I'm also interested to contribute to this issue for the Mentorship program, but I'm not sure whether I can opt for different issues or not 🤔 In case it's only possible to opt for just one issue, I wouldn't mind to pick one or the other depending on the priority or importance of the issue for AsyncAPI, I can adapt to it :)

(The other issue I'm talking about is #184)

[jonaslagoni]

@fmvilas any reason this was added with gsoc 😄? As there already is a PR that adds it and we are currently stuck based on the feedback with no way to really move forward 🤷

#173

[fmvilas]

Oh sorry, I haven't seen it. Removing the label then.

[peter-rr]

Alright, you can ignore my previous comment then :)

[asyncapi-bot]

🎉 This issue has been resolved in version 0.21.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀