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

Support for Mutiny Return Type on Specific Endpoints #782

Closed
oben01 opened this issue Aug 28, 2024 · 7 comments · Fixed by #788
Closed

Support for Mutiny Return Type on Specific Endpoints #782

oben01 opened this issue Aug 28, 2024 · 7 comments · Fixed by #788
Assignees
Labels
area:client This item is related to the client extension enhancement New feature or request

Comments

@oben01
Copy link
Contributor

oben01 commented Aug 28, 2024

Description:

I would like to suggest a feature enhancement for the OpenAPI Generator in Quarkus, specifically regarding the generation of Mutiny-based return types for specific API operations. Currently, it seems that Mutiny support is either globally applied. However, there are use cases where only certain endpoints need to leverage Mutiny’s reactive capabilities.

Proposed Solution:

Introduce the ability to apply Mutiny return types selectively to specific operations within an OpenAPI specification. This can be achieved by adding configuration options that allow developers to specify which endpoints should have Mutiny return types.

Example Configuration:

quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny=true
quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny.operation-ids=addPet
# For multiple operation IDs:
quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny.operation-ids=addPet,updatePet

*if only mutiny=true we continue to apply to all endpoints

Use Case:

Consider an OpenAPI specification, such as the one used in the Swagger Petstore example. If a developer only wants to apply Mutiny return types to the POST /pet endpoint, they could use the configuration above. This allows for granular control, enabling developers to optimize specific parts of their API for reactive processing without globally applying it to all operations.

Expected Outcome:

  • The specified endpoints (e.g., POST /pet) would have Mutiny-based return types.
  • Other operations would retain their default return types unless explicitly configured.

Feedback Request:

I would appreciate your thoughts on the feasibility of this feature. Are there any potential challenges or considerations that I might have overlooked?

Thank you for considering this enhancement!

@ricardozanini
Copy link
Member

Hi @oben01! That's a great addition to the extension. If you don't mind, can you work on a PR?

Cheers!

@ricardozanini ricardozanini added area:client This item is related to the client extension enhancement New feature or request labels Sep 4, 2024
@oben01
Copy link
Contributor Author

oben01 commented Sep 4, 2024

Hello @ricardozanini Thank you for the positive feedback! I'd be happy to give it a try and work on a PR for this feature.

Additionally, I was thinking of expanding the feature to allow developers to choose between Uni and Multi return types for each endpoint. This would provide even more flexibility depending on whether a single response or a stream of responses is expected from an endpoint.

I'll start working on this and keep you updated on my progress!

@oben01
Copy link
Contributor Author

oben01 commented Sep 4, 2024

What do u thing of something like :

quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny=true

# Configure return type for specific operation IDs
quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny.operation-ids.addPet=Uni
quarkus.openapi-generator.codegen.spec.my_openapi_yaml.mutiny.operation-ids.updatePet=Multi

@ricardozanini
Copy link
Member

Great idea!

@oben01
Copy link
Contributor Author

oben01 commented Sep 10, 2024

@ricardozanini The PR is ready :)

@oben01
Copy link
Contributor Author

oben01 commented Sep 11, 2024

@ricardozanini I just forget to run mvn verify to reformat the code sorry about that. could u please run the pipeline again

ricardozanini pushed a commit that referenced this issue Sep 16, 2024
Co-authored-by: oussama Dahmaz <dahmaz@MacBook-Pro-de-odahmaz.local>
FelixScherzinger pushed a commit to FelixScherzinger/quarkus-openapi-generator that referenced this issue Sep 18, 2024
…quarkiverse#788)

Co-authored-by: oussama Dahmaz <dahmaz@MacBook-Pro-de-odahmaz.local>
@kfebert
Copy link
Contributor

kfebert commented Sep 19, 2024

Great feature, looking forward to use it in the next version. :-)

Just a question since my own trial showed that it seems to clash with the feature returnReponse=true which generates Multi on an explicitely specified operation that returns byte[] in my case:

Would it be possible to have another option that offers to generate it without the response as it does not make much sense, does it?

Meaning Multi<byte[]> in my case.

I am happy to provide more details if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:client This item is related to the client extension enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants