OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
Is your feature request related to a problem? Please describe.
I am using the java/kotlin spring generators exclusively with the interfaceOnly flag set to true.
This option in those generators were the key to achieve contract first development with openapi-generator when multiple teams depending on the code that is generated from the spec.
I am interested what the maintainers and the community thins about this approach. How well this would fit into the current generator. If this is something that worth adding then I am also open to contribute this.
@andriy-dmytruk
Describe the solution you'd like
Replicate the spring generators interfaceOnly behaviour for the micronaut generator.
Describe alternatives you've considered
The generateControllerAsAbstract does something really similar, but the output still an project skeleton. It includes the Application class, application.yaml, the controller package with default impls, tests, and shadow jar plugin for builds.
For the library approach, these are all unnecessary and also block building just a regular artifact with only pojos and interfaces.
Additional context
I will provide some context how I would implement contract first interface design through an example:
The workflow goes like this:
each team has their own repository, e.g. frontend with some js framework, an analytical app in python, and the backend with the micronaut app
the OpenAPI specification is living in a separate repository
in the repository with the OpenAPI specification theres a tooling that generates artifacts for each team relying on the this - npm package for the frontends, python "sdk" in a PyPl package, and a JAR for the server, maybe Feign clients if there are multiple backend services
Client generators are inherently (at least the ones I used so far) generates code in library layout that can be packaged and distributed, so nothing surprising there.
Spring interfaceOnly only generates annotated models and annotated interfaces for the APIs. No application class, no application yaml. no dev tools dependency or spring boot repackage plugin. This is really nice because this can be built and distributed as a regular jar, as library.
After this, we just pull this JAR as a dependency into a regular spring boot app generated by spring initializer for example, and implement the interfaces.
This way the contract can evolve independently from the backend. Clients can start development even without the backend by using the generated API code and using stubs/mocks for testting.
As an additional feature, an improvement over how the spring interfaceOnly feature works, these builds would also attach a sources jar to the published artifact. This helps developers when they are inspecting the generated files that are imported as a dependencies - it always much nicer to look at sources instead of decompiled class files. It would also retain javadoc (which is not really relevant as the micronaut generator not outputting them)
Is your feature request related to a problem? Please describe.
I am using the java/kotlin spring generators exclusively with the
interfaceOnly
flag set to true.This option in those generators were the key to achieve contract first development with openapi-generator when multiple teams depending on the code that is generated from the spec.
I am interested what the maintainers and the community thins about this approach. How well this would fit into the current generator. If this is something that worth adding then I am also open to contribute this.
@andriy-dmytruk
Describe the solution you'd like
Replicate the spring generators
interfaceOnly
behaviour for the micronaut generator.Describe alternatives you've considered
The
generateControllerAsAbstract
does something really similar, but the output still an project skeleton. It includes the Application class, application.yaml, the controller package with default impls, tests, and shadow jar plugin for builds.For the library approach, these are all unnecessary and also block building just a regular artifact with only pojos and interfaces.
Additional context
I will provide some context how I would implement contract first interface design through an example:
The workflow goes like this:
Client generators are inherently (at least the ones I used so far) generates code in library layout that can be packaged and distributed, so nothing surprising there.
Spring
interfaceOnly
only generates annotated models and annotated interfaces for the APIs. No application class, no application yaml. no dev tools dependency or spring boot repackage plugin. This is really nice because this can be built and distributed as a regular jar, as library.After this, we just pull this JAR as a dependency into a regular spring boot app generated by spring initializer for example, and implement the interfaces.
This way the contract can evolve independently from the backend. Clients can start development even without the backend by using the generated API code and using stubs/mocks for testting.
As an additional feature, an improvement over how the spring
interfaceOnly
feature works, these builds would also attach a sources jar to the published artifact. This helps developers when they are inspecting the generated files that are imported as a dependencies - it always much nicer to look at sources instead of decompiled class files. It would also retain javadoc (which is not really relevant as the micronaut generator not outputting them)