The Future of Glee (https://github.com/asyncapi/glee)

[oviecodes]

Recently, I discussed the future of Glee (https://github.com/asyncapi/glee) with @fmvilas, noting that it is no longer actively maintained. He helped me realize that while Glee has been great at showing how a different kind of framework is possible, it would be better to implement similar functionality to Glee in Spring Boot and Spring Cloud Stream rather than creating a new framework. This is mainly because most developers working with EDA use Java and are reluctant to switch to TypeScript or JavaScript. Additionally, many cannot make the switch due to the significant effort they have already invested over the years, making the introduction of a new language or framework a daunting prospect.

This is a great idea from @fmvilas, so I would like to know if such a tool currently exists in the AsyncApi community. I'm opening this discussion to get a consensus on whether this is worth pursuing and also the appropriate direction to go.

@fmvilas @Souvikns @derberg @jonaslagoni @KhudaDad414

[thulieblack]

@oviecodes it'll be nice to have a community wide discussion and visibility on the topic. You might also consider putting it in the next community meeting agenda

[fmvilas]

Yeah, my suggestion is exactly that. However, if people are still interested in keeping it alive, that's also great. Glee has a lot of potential but only if a few really dedicated maintainers give their time. It's not an easy task with all those protocol adapters and edge cases. I love the concept of Glee –as you can imagine— but in my experience almost no one doing event-driven architecture is using TypeScript or JavaScript (maybe WebSockets, if at all). The rest are using mainly Java (with Spring Boot and Spring Cloud Stream) and Go. Even Go is a minority here. I wished I had the numbers but I'm just speaking from conversations with developers all over these years.

That said, for TypeScript and JavaScript, there's a big potential in the browser. Creating applications that run in the browser using HTTP, WebSocket, MQTT over WebSocket, and Socket.IO following the Glee approach would be amazing. That's why months ago I extracted the core and the adapters, just so we could choose not to have libraries that don't work in the browser. That would make the framework more manageable and unique of its kind.

That's my two cents.

[oviecodes]

@fmvilas I'll be willing to take up this task, but honestly, I'll need some guidance on what path to take and some other decisions that may arise in the future.

[fmvilas]

I'm going nowhere. I'll be happy to provide guidance.

[oviecodes]

alright @fmvilas i'm glad to hear that

[oviecodes]

I'll start by looking at the current means by which async programming is done in Spring Boot, what do you think about this @fmvilas

[fmvilas]

Yeah, I recommend that you have a look at their docs and examples. With this, try to create a prototype. It doesn't have to be perfect. Just some things may work but enough for you to make sense of it. Honestly, I think if you ask an LLM to create something like that it should take you pretty close. That's another way for you to learn.

[oviecodes]

I appreciate this @fmvilas

[oviecodes]

@fmvilas I couldn't find a java parser for asyncapi. If there's none, I could build that first.

[fmvilas]

@lbroudoux @ivangsa you guys know about something @oviecodes could be reusing?

[ivangsa]

hey @oviecodes 👋

I'm the maintainer of this SDK that generates all the boilerplate code for Spring Cloud Streams from asyncapi: Typed DTO's, Typed Headers (with support for runtime expressions), and full producer / consumer boilerplate code...

It differs from Glee in that it only takes into accound the domain modeling of the application, it doesn't take into account the configuration of which server (or even which actual topic it will connect to). That is left to the developer team to provide that configuration using any of the multiple ways to configure spring-boot/spring-cloud (using the application-<profile>.yml is the most common way)

As for a java parser, it does not implement a "typed parser", it uses this json-schema-ref-parser-jvm to parse json/yaml and resolve $refs and then JsonPath expressions to navigate and iterate the resulting json structure (for instance things like this: JSONPath.get(consumerOperations, "$.[*]message..payload..[?(@.x--entity)]"))

Have a look at this doc and video and see if this matches your vision... you will be more than welcome to contribute and help maintaining and evolving the SDK. Very happy to hear your ideas..

https://www.youtube.com/watch?v=d5xddNWYR5I
https://www.zenwave360.io/zenwave-sdk/plugins/asyncapi-spring-cloud-streams3/

[lbroudoux]

@lbroudoux @ivangsa you guys know about something @oviecodes could be reusing?

Nothing I'm aware of... The parser in Microcks is not a general-purpose parser and just focuses on extracting info from the AsyncAPI spec to fill the Microcks metamodel description. So nothing reusable, I fear.

The reusable part we have is the validator library that allows, given an AsyncAPI spec, to check if a message (textual or Avro encoded) is conformant to the expected schema.

[oviecodes]

Thanks for the information, guys. @ivangsa I'll take a look at the SDK.

[oviecodes]

@ivangsa This is a great tool. From the video and the documentation, I can see that the SDK handles code generation, boilerplates, headers, and other useful features. It also allows creating these modules as producers or consumers, but Spring Cloud Streams handles the actual connection to brokers and other related tasks, such as security. I tried out Spring Cloud Streams, and it does the majority of what Glee does. I think this SDK has covered most of this scenario, @fmvilas, what do you think? It seems like writing another Glee in Java would be like a direct competition for Spring Cloud Streams.

[fmvilas]

Nothing to add that Ivan hasn't said already :) Experiment and evaluate. Start with the user experience (DX in this case) in mind and walk back from there. Build whatever is missing.

[ivangsa]

@oviecodes thanks for taking the time for this ;-)

I think zenwave-sdk is very close to be an schema-first tool but as it is right now you always need to configure at least two plugin executions: one for the DTOs and one for the SpringCloudStream boilerplate... and that is because the developer needs to make the decision of generating plain java DTOs or use an Avro generator...

I'm not advocating to replace the two current plugins, but maybe provide a new one that reads the asyncapi.yml and based on the content, configures internally the DTO code generator wrapping either POJO generator or the Avro generator.. Avro generator is a pain to use bc if you have dependencies between .avsc files you need to import them in proper order to the plugin... If we solve this for endusers would be awesome..

One thing that Glee does that zenwave doesnt even try, is configuring the connection to the broker (server and topic details)... While I think this could be done with some Spring-Boot autoconfig code... It would take experienced spring-boot practitioners, but we could give it a try in a experimental lib..

What I mean, is that there is room to make zenwave even closer to the Glee original vision: schema-first, always up-to-date to latest spec, developer centric focused on ther remaining business logic..

[oviecodes]

Thanks for the response @ivangsa
These are wonderful ideas. I'd be happy to look into them with you and see how far this can be pushed.
I'd take the weekend to try out the SDK, so I can have some in-depth understanding of how things fit together.

[ivangsa]

Hi @oviecodes

if you are interested joining zenwave development I created these issues to improve DX experience and closer to Glee vision:

• feat (plugins/avro-schema-generator): New Plugin for Generating Avro Java classes from .avsc files ZenWave360/zenwave-sdk#60 "New Plugin for Generating Avro Java classes from .avsc files (order lenient)"
• feat(plugins/asyncapi-stream-cloud-stream-wrapper): Create a new plugins that wraps JsonSchema2Pojo and SCS plugins ZenWave360/zenwave-sdk#61 "Create a new plugins that wraps JsonSchema2Pojo/Avro and SCS plugins"
• feat(DefaultYamlParser): Add Auth Support for HTTPS URLs ZenWave360/zenwave-sdk#62 "Add Auth Support for HTTPS URLs"

It would facilitate the configuration for code generator to one single maven plugin execution that does all the heavy lifting for dev users.

This will make the asyncapi.yml spec file the single source of truth for all the boilerplate code, that if configured as recomended, every build would generate all the code for the latest spec. Becoming a truy "Spec First" toolkit.

(feel free to join at your own pace if interested. you can join Discord channel if you need guidance starting with the project...)

[oviecodes]

Hi @ivangsa, Thanks a lot.

I'm certainly interested in joining ZenWave development.

Going through the documentation is taking me longer than I expected, mainly because I've been somewhat occupied, and I'm also taking the time to understand it. I'll take a look at these issues soon. Also, I just joined the Discord.

[derberg]

Closing as Glee was archived: https://github.com/asyncapi-archived-repos/glee as part of the TSC vote: #1948