AsyncAPI Initiative
Roadmap for making a seamless API development experience #237
jonaslagoni
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
|
They seem reasonable to me. I'd love to know more details about each one though. I think you should create issues for each of these things and explain what you have in mind. This will also make it easier for people to discuss and track. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Good point, definitely will, once we agree on the concrete vision! This was just to give the bigger picture, so hopefully, the small details gave enough of an idea about what it contains 🤞 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I wanted us to clarify our roadmap with more specific goals for how we can make the development experience seamless for developers and how we want to help them develop EDA's and API's.
Expanding to the overall goal, the following are the sub-goals that all other outcomes focus on. The goal here is to create the absolute best toolbox for developers to work from an AsyncAPI file.
Creating an API in under 20 minutes with no prior knowledge of AsyncAPI
The first hurdle everyone encounter after creating an AsyncAPI document is to figure out how they can implement their API.
This is regardless of what programming language (TypeScript, Golang, C#, C++, ...) you want to develop your API in. Regardless of what underlying protocol (NATS, Kafka, HTTP, WS, ...) you are using. Regardless of whether you want to use a framework (Glee, ...) or code generation (templates).
Creating an API should be as easy as maintaining one
Creating an API is just the first hurdle, what happens when you need to maintain one, and keep integrating features?
Making changes to your API should be as easy as creating it, regardless of whether you use a framework or code generation in your workflow.
How do we get there?
The answer, together 😄 Seriously, it is, without everyone getting involved, providing this vision will be impossible. The following is how I suggest we get there.
Now
What is in focus now?
User is able to focus only on business logic
Creating a framework
The first step is creating the framework to one specific protocol in one specific language.
Making it easier to work with templates
For the later goals, we need to improve the generator in a number of ways.
User has access to all the tools through a single interface
In order to give the developer the best UX possible, we need a core CLI where everything can be run through. @Souvikns and @jotamusik already have it well underway 💪
Later
What is in focus later?
Make it easier to work with code generation
We need to make sure that we don't only offer tools to start projects, but also maintain and further develop them.
Make it easier to test implementations
Whether you use code generators, frameworks, or something else, we should make sure that we can create tests such as API and unit tests as it can be done based on the AsyncAPI document. So all you need to focus on is the business logic.
Make code generated projects easily adaptable to changes in the API
When you use code generation, sometimes it is not straightforward how you can integrate it into your development workflow. What happens when you need to add a new feature, make a breaking change? We need to make sure that we have solved this perspective.
Make Glee projects easily adaptable to API changes
When you use code frameworks, sometimes it is not straightforward how you can integrate them into your development workflow. What happens when you need to add a new feature, make a breaking change? We need to ensure that we have solved this perspective.
User is able to focus only on the business logic in any protocol
Make Glee support more protocol
Now that we have the basics of the framework done, we need it to support any protocol. At least this includes:
Have a code generator for each protocol
Now that we have the foundation for creating code generators We need it to support any protocol. Many already work on this, which is perfect 👍 At least this includes:
Future
What is in focus in the future?
Users should be able to easily work with AsyncAPI files
Enable easier editing of the AsyncAPI file
We need a way for other tools to edit an existing AsyncAPI file. This can be especially useful for CI scripts and other tools, where you need to modify an existing document.
Make it possible to detect types of changes
We need a way to figure out which types of changes are introduced to an AsyncAPI document. This way it is easier to automate a bunch of tasks. @aayushmau5 already have this well underway!
User is able to focus only on the business logic in any scenario
Create AsyncAPI plugins for most common frameworks
Developers generally don't want to switch frameworks just for the sake of it, so integrating AsyncAPI into existing frameworks would give the developer the best way to use it.
Make Glee support multiple languages
Not everyone loves TypeScript, developers should be able to use their preferred language. At least this includes:
Have a code generator for each protocol regardless of language
Not everyone loves TypeScript, developers should be able to use their preferred language regardless of what protocol they are using. Many already work on this, which is perfect 👍 At least this includes:
Thoughts?
These are of course just my thoughts, and it very well might happen they need to change in the future, but this at least gives a good vision for what's to come. How do you see the vision for
After the discussion dies down and we agree on the vision, I will make sure the roadmap reflects it 🙂
Beta Was this translation helpful? Give feedback.
All reactions