glee

glee copied to clipboard

Reason/Context

One of the challenges I face when using Glee is the uncertainty of the values in message payloads. Seeing the "any" type in Typescript can also be a bit intimidating. 😆

However, AsyncAPI provides a helpful feature that allows us to describe the message payload format using JSON Schema. With the use of https://github.com/asyncapi/modelina, we can conveniently convert these schemas into Typescript Types.

Where to start?

Step 1

Use Modelina and generate the types from the AsyncAPI file. Categorize the message payload type by the operationId. for example we can have types/operations/hello.d.ts for hello operation in .glee folder. It would be great for this file to contain the whole function type so it can be easily used in hello.ts function.

Step 2

When we generate a Glee project for an AsyncAPI file, Glee should create empty blueprints for all of the operations and assign the correct types to them. this way, user can start with the blueprint and get all of the type safety and suggestions for their message payloads.

@jonaslagoni I don't have that much experience with Modelina and not sure if it's feasible. WDYT? 🤔

How about we create a CLI function to generate types on the go based on the operationId added or changed in AsyncAPI file. (Just a thought)

I’m looking to implement the idea of creating blueprint files for the message payloads in the AsyncAPI file during the generation of glee project.

That should definitely be possible yea 👍

In the early stages of Glee we also did this for Java, so you could have Glee functions in Java where the signature of the function was generated by Modelina, like you are proposing for TypeScript. So yea definitely possible 💯

Feel free to reach out if you have any questions or problems 🙂

How about we create a CLI function to generate types on the go based on the operationId added or changed in AsyncAPI file. (Just a thought)

@SinghiHarsh I think @peter-rr is working on generating glee projects from an AsyncAPI file in cli(If I am not mistaken) I guess step 2 can be done there?

I’m looking to implement the idea of creating blueprint files for the message payloads in the AsyncAPI file during the generation of glee project.

that's great. 🌟 please reach out if you had any questions :)

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:

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:

@KhudaDad414 issue still valid? cc: @jonaslagoni

@AnimeshKumar923 This is a valid issue. To address it, we might need to implement this feature in two places:

• Glee Generator Template: For initial type generation when the project is created (Glee Template: https://github.com/KhudaDad414/glee-generator-template).
• Glee Runtime: To dynamically regenerate types when the AsyncAPI file changes.

The challenge is that The Glee Generator Template runs only once. How can we ensure types remain synchronized with AsyncAPI changes afterwards?

Possible Considerations:

Could Glee monitor the AsyncAPI file for changes? Can type regeneration be triggered by the user for better control?

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: