-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Spring Support #235
Comments
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. |
Reducing the maintenance cost by consolidating the Java variants makes sense to me, as long as you're confident that it is feasible - and your fork seems to support that. I don't have any objections to this - thanks very much for the proposal! I'd like to hear what the maintainers of the other templates think too - @Tenischev @derberg @CameronRushton - as they may be aware of benefits of keeping them separate that I'm not aware of. |
I'm definitely prefer such approach. At it makes sense with the vision of pulling templates inside generator repo. Better to work together on one template in one repo and not duplicate efforts, instead of maintaining 3 independent template that most probably duplicate a lot of work |
Sounds good, hopefully next week I'll have some time to potentially put together a more thorough PoC. One thing I was trying to figure out last time though is if its possible to specific nested parameters to the generator... I was thinking of adding something like Obviously this could be achieved by only using camelCase, but it just providers for more granular namespacing of parameters which will likely become more used if Another thing I was trying to work my head around of if asyncapi has the concept of client vs server and if it makes sense in an eventing context. This would be my first time using AsyncAPI coming from using OpenAPI for quite a few years now where this is clearly defined. In OpenAPI you are able to either generate server stubbings, basically an interface that handles the incoming requests that a developer then needs to implement the business logic for. Or a client, which is a an implementation that can be used to invoke remote APIs. My thoughts on this for AsyncAPI would be: Server:
Client (basically the inverse):
However, I'm not convinced this is correct. I did have a quick look through the docs and online but I couldn't seem to find much at the time, do you have any best pracitices for how AsyncAPI should be designed for use in a microservices architecture? I assume it should be a single AsyncAPI document per microservice, but in that case I would expect microservice A to only specify |
I've now found this about the Command and Event terminology. However, there doesn't seem anyway in AsyncAPI to describe a message as this unfortunately. |
Why do we need this improvement?
Currently there are two seperate templates that include spring support:
However, neither of these support the AsyncAPI v3 schema.
How will this change help?
Having mutliple repositories that all need to be upgraded when newer schema versions are released clearly isn't working as there are many repositores that still don't support it 10 months after release.
Having a single java template that can be configured will help keep things up to date, as well as reduce the duplication as models etc. should remain largley unchanged between different implementations.
Screenshots
No response
How could it be implemented/designed?
I propose that a new
library
parameter is added to this template, that can acceptjava
(default, current implementation) andspring
.I would also suggest adding futher configuration options, such as
artifactType: [app, library]
to add the option to generate a library that could be imported like how OpenAPI does. Configuraiton options that are specific to each type of protocol/library to allow further customisation coud also be implemented.I have very breifly started to work on a fork that can be found here for Spring Kafka support, and I would just like to explore if this is something you would consider accepting to be merged into this project before I design in it a way that would be comptaible.
🚧 Breaking changes
No
👀 Have you checked for similar open issues?
🏢 Have you read the Contributing Guidelines?
Are you willing to work on this issue?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered: