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

Generate feign clients from OpenAPI definition files #9548

Closed
1 task done
ecostanzi opened this issue Apr 9, 2019 · 7 comments
Closed
1 task done

Generate feign clients from OpenAPI definition files #9548

ecostanzi opened this issue Apr 9, 2019 · 7 comments

Comments

@ecostanzi
Copy link
Contributor

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: #3649
Feign client annotations: #7756
Improve service to service communication: #6450
cbornet/generator-jhipster-swagger-cli#13

  • Checking this box is mandatory (this is just to show you read everything)
@PierreBesson
Copy link
Contributor

PierreBesson commented Apr 9, 2019

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
Copy link
Contributor

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
Copy link
Member

cbornet commented Apr 23, 2019

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
Copy link
Contributor Author

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
Copy link
Member

cbornet commented Apr 23, 2019

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants