Generator-jhipster: Generate feign clients from OpenAPI definition files

[ecostanzi]

Overview of the feature request

Allow developers to generate feign clients from OpenAPI definition files. This could be done by integrating the code of the module https://github.com/cbornet/generator-jhipster-swagger-cli created by @cbornet.

Motivation for or Use Case

Improve communication and the integration between microservices.

Example

I ran yo jhipster-swagger-cli on a microservice and then modified the code using the maven plugin instead of the npm module. This is how it looks like, could be a starting point.

Possible Implementations

1. Modify the main generator with a new property in the .yo-rc.json

...
"openApiClients": ["petstore", "anotherClientSpec"]
...

1. A separate generator openapi-cli

$ jhipster openapi-cli
Do you want to specify a path to an existing spec? (Yes/no) 
Yes -> Where is your Swagger/OpenAPI spec (URL or path) ? / Do you want keep a copy of the spec into the workspace?
No -> create a empty yml into the resources folder
What is the name of the client? (petstore)

Open questions and consideration

• Will the generator allow to generate more than one client?
• Even when passing a URL to the generator, I would suggest to keep a local copy of the spec file versioned into the workspace. This way the compilation keeps working out-of-the-box.

There are certainly other aspects I didn't consider. According to this @cbornet and @PierreBesson have already discussed about this feature so I'd be glad to know their opinion.

Related issues or PR

Communication between microservices: https://github.com/jhipster/generator-jhipster/issues/3649
Feign client annotations: https://github.com/jhipster/generator-jhipster/issues/7756
Improve service to service communication: https://github.com/jhipster/generator-jhipster/issues/6450
https://github.com/cbornet/generator-jhipster-swagger-cli/issues/13

• [X] Checking this box is mandatory (this is just to show you read everything)

[PierreBesson]

Yes this is a good idea and something we need to push. Note that the openapi-generator could also be integrated with the cli (installed from the openapi-generator npm dependency).

This openapi codegen feature could also be used to generate clients on the front-end for angular httpClient and axios for react.

[PierreBesson]

I think this feature is important for our microservice support to help going beyond the hello-world. It's also good for the collaboration between JHipster and OpenAPI-generator which are 2 complementary code generation projects.

I just wonder if we should use the openapi-generator jar from the npm dependency or the maven/gradle plugin. @cbornet do you have a preference ?

[cbornet]

I would say it's better to generate from npm so the code is generated as part of the project scaffolding and not during an additional compile step.

[ecostanzi]

I would say it's better to generate from npm so the code is generated as part of the project scaffolding and not during an additional compile step.

How would this work if the spec file changes? The openapi npm module should be triggered by maven or gradle in order to be sure that the backend generated code is aligned to the latest version of the file.

(Speaking only considering the possible backend drawbacks as I'm not so skilled on the frontend side)

[cbornet]

How would this work if the spec file changes?

You would regenerate your client with the yeoman generator. That's how the module works currently.

[PierreBesson]

Yes it would have to be regenerated. This is a bad practice to couple your client code with the API spec. It prevents the server and client code from evolving independently.

[ecostanzi]

I managed to import @cbornet module into a jhipster submodule. I drafted some ideas in the todo list in the pull request. Please let me know if this is what you guys had in mind.