Skip to content
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

Open
2 tasks done
rj93 opened this issue Oct 22, 2024 · 5 comments
Open
2 tasks done

[FEATURE] Spring Support #235

rj93 opened this issue Oct 22, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@rj93
Copy link

rj93 commented Oct 22, 2024

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 accept java (default, current implementation) and spring.

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?

  • I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

Are you willing to work on this issue?

Yes I am willing to submit a PR!

@rj93 rj93 added the enhancement New feature or request label Oct 22, 2024
Copy link

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.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

@dalelane
Copy link
Collaborator

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.

Copy link
Member

derberg commented Oct 28, 2024

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

@rj93
Copy link
Author

rj93 commented Oct 28, 2024

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 spring.kafkaVersion, to be used as the dependency version if specified. Is this somethings that would be possible?

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 artifactType is to be implemented.


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:

  • recieve operations would generate an interface that would need to be implemented by a developer
  • send operations would generate a client to emit the event
  • request/reply - operations would generate an interface to recieve, and a client for the reply

Client (basically the inverse):

  • recieve - operations would generate a client to emit the event
  • send - operations would generate an interface that would need to be implemented by a developer
  • request/reply - operations would generate a client for the recieve, and an interface for the reply

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 recieve operations (and potentially request/reply) in it's public API. If microservice A needed to emit an event that microservice B listens to, it would generate a client implementation of microservice B's public API. Any recommendations/documentation links on this aspect would be greatly appreaciated.

@rj93
Copy link
Author

rj93 commented Nov 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants