Projects ideas
We have 7 mentors from TSC and 2 mentees from the TSC, giving us 23 remaining TSC members able to vote.
Ideas list
| Number | Idea | Area | Lead mentor | Why should it be picked? |
|---|---|---|---|---|
| 1 | Add support for HTTP servers and clients | Glee | @Souvikns | With creating HTTP servers to connecting to webhooks from a AsyncAPI definition, Glee will be able to achieve so much more with the HTTP protocol support. |
| 2 | Add support for AMQP 1.0 | Glee | @fmvilas | AMQP 1.0 is the one of the most used protocols in big corporations (e.g., banks, retail, etc.). This will give us the opportunity to stress test Glee in production. |
| 3 | Add support for AMQP 0-9-1 | Glee | @fmvilas | AMQP 0-9-1 is one of the most popular protocols because it's the one powering RabbitMQ by default. This will give us the opportunity to grow Glee's user base and test it in production. |
| 4 | Add support for Kafka | Glee | @fmvilas | Kafka is the most popular broker and protocol nowadays. This will give us the opportunity to grow Glee's user base and test it in production. |
| 5 | Making testing easier with Glee | Glee | @fmvilas | Glee has to manage a bunch of protocols, schema formats, examples, and even support for other programming languages in the future. To release a new version, we should always be confident that we're not breaking anything. This issue is about that, developers' calm of mind 😄 |
| 6 | Library for easier integration testing of code generators | Generator | @derberg | AsyncAPI Generator is in a shape where writing a template is easy, but testing it not so. We have guides on how to write unit tests for components and snapshot testing for generation result. There is no easy way to say how to do integration tests for generated apps. We need a library that you can just plug into your template, configure, provide AsyncAPI files to test against and as a result you get basic testing environment for specified broken. In the end, you do not have to manually check each change in the template for each supported protocol. |
| 7 | Rewrite this template and NodeJS WS template to new react rendering engine | NodeJS Template and NodeJS WS Template | @derberg | AsyncAPI Generator supports React templating, and goal is to get rid of Nunjucks. All new templates that are created follow React. We need to rewrite existing Nunjucks Nodejs templates to React, so we finally can do React a default engine, and add more features to these templates. |
| 8 | Drag&drop AsyncAPI block builder | Studio | @magicmatatjahu | drag&drop - We are missing a tool in our ecosystem that would allow us to build AsyncAPI specifications using drag&drop blocks and combine them creating channel -> operation -> message relations etc. This can be compared to event storming but based on AsyncAPI. The project itself should allow to build AsyncAPI documentation from scratch, update the existing one or just visualize the specification with blocks. |
| 9 | Website UI Kit design/dev project | Design System | @mcturco | The idea for the Website UI kit was to streamline contributions/changes to the website, providing a pre-set list of React components that are ready for content (similar to how Tailwind UI components are). Imagine if we could have a set of components that match the brand and take the guesswork out of creating new pages and whether a section is accessible, usable, and functional. It would be great to have a component set in which you can create new pages with, instead of contributors asking for a design mock-up. Even if we still needed to provide a mock-up, these components could be saved into a Figma library, and a designer could go ahead and lay out the idea for the page using the already-developed components. Cuts contribution time in half! Plus, we could continue to scale this UI kit over time if we feel like we need to make additions/adjustments. |
| 10 | An interface/project for describing errors/problems in tools in our organization | New library | @magicmatatjahu | An interface/project for describing errors/problems in tools in our organization - We have many tools in our organization. Some of them have their own error/problem handling system, others don't have it at all and only throw exceptions from the main function. I think we should standardize this and propose a system based on an interface called problem (more about it in https://lakitna.medium.com/understanding-problem-json-adf68e5cf1f8 among others), but tailored to the tools and not to the API (we should use our problem system for that too). The result of the project will be a @asyncapi/problem library which we can easily use in our other projects and in the integration tools (Studio, CLI, ServerAPI) we can easily consume and handle the error messages thrown from our tools like generator, parser etc. |
| 11 | Modelina website | Modelina | @jonaslagoni | Modelina has so many different use-cases and specifics that need to be documented and explained in different formats, that having one single page on the official page is not enough. This idea lay the foundation for how not only Modelina, but any other tool we have, can create a dedicated website. |
| 12 | Improvements to Modelina playground | Modelina | @jonaslagoni | With so many different inputs (AsyncAPI, OpenAPI, JSON Schema, TypeScript, and more to come) and specific outputs (TypeScript, C#, Go, Java, JS, and more to come) a playground that shows the full force of the tool is beyond desired. It makes the tool more discoverable, and shareable and enables you to deep dive into what the tool is capable of within minutes. |
| 13 | Build a React app to visualize GitHub Actions across the organization | AsyncAPI CI/CD | @KhudaDad414 | We are an automation-driven community and we use GitHub Actions to automate lots of things in the organization. GitHub actions aren't unlimited and we need to have a clear picture of what workflows are using what amount of resources and how we can get the most out of GitHub Actions. GitHub currently doesn't provide such a tool to monitor and see the statistics about workflows across the organization. |
| 14 | MVP integration of extensions catalog with AsyncAPI tools to make extension catalog useful | Extension Catalog | @derberg | - We need to finally have some simple integration of extensions into existing tools to promote the concept more and show that it is useful to share extensions with the community, as shared extensions will always be supported. - It is also super critical for the work on new specification features, as it is always better to first add extension, check it on production and then turn it into a feature. |
| 15 | Make it easier to create templates and glee projects | CLI | @fmvilas | We're doing a great job at Glee and Generator and it's about the get even better. However, we need it to be easy for users to create their own templates and Glee projects. And even more important, it needs to be easy for them to discover these projects actually exist. CLI should be the place where people can find and use these technologies. |
| 16 | Create New page for /tools/ | Website | @derberg | Current list of community tools depends on tools owners to open up a PR. It is extra effort that is hard even for us, AsyncAPI maintainers, and therefore many AsyncAPI tools are not properly promoted on AsyncAPI Website. Goal here is to improve discoverability of AsyncAPI tools, make it easier to add new ones to the list, without PR, and also have more sophisticated navigation/filtering |
| 17 | Add support for an HTTP/FaaS runtime | Glee | @fmvilas | There's a growing list of people and companies doing serverless or Function-as-a-Service (FaaS). Making Glee integrate with serverless providers will allow users to code and manage their functions in their favorite language and platform while still leveraging the power of Glee. |
| 18 | Add support for retries, backpressure, and at-most-once, at-least-once, and exactly-once semantics | Glee | @fmvilas | This is probably the most complicated issue in difficulty. If we want people to adopt Glee in production, it needs to be production-ready, and that means being able to handle huge loads, network failures, and avoid losing messages (when the protocol allows it). |
| 19 | Automate listing of members of technical steering committee | Project governance | @derberg | There is a lot of work done already for handling TSC related processes on GitHub. But there are still few more things to do in org like ours: - we need to be able to automatically discover changes in CODEOWNERS and update them in a list of TSC members - we need to communicate changes in automated way, twitter/email, as there is no one who can do it all the time |
