added console client #604
added console client #604
Conversation
| <goal>generate</goal> | ||
| </goals> | ||
| <configuration> | ||
| <inputSpec>https://console.cloud.camunda.io/customer-api/openapi/swagger.json</inputSpec> |
There was a problem hiding this comment.
This is some cool stuff. I never used a generator before. I need to see if shall we go the generator route, or write out the API models ourselves. Wondering what are the advantages and disadvantages.
The route I've been going is to manually add the classes and use sensible names (since TaskList, Operate and others from what I've seen are using different convention). I understand that going thru the generated route reduces time to market, and maintenance I assume would be easier since whenever they update their version we can just generate again and modify the wrapper classes calling it.
There was a problem hiding this comment.
I think we can go the generator route for all APIs that offer some kind of spec.
I see that this kind of refactoring would probably cost some effort, but also reduce the amount of code to be maintained.
There was a problem hiding this comment.
This is looking awesome. I think I want to improve a couple of things by
- see if we still want to use the generator approach (the other modules are hand-crafted models). We can go the route of this being generator, and the remaining are hand-crafted and see how will versioning and maintenance will look like whenever there is a change in the API
- I'd like to reuse the existing
httpmodule. Theres some refactoring involved.
I'm more than happy to do those changes, but wanted to get your opinion. Overall this speeds things up and this is greatly valued!
| public DefaultApi get() { | ||
| ensureApiClient(); | ||
| return api; | ||
| } | ||
|
|
||
| private void ensureApiClient() { | ||
| if (api == null) { | ||
| HttpRequestInterceptor interceptor = | ||
| new AuthenticationInterceptor(Product.CONSOLE, authentication); | ||
| CloseableHttpClient httpClient = | ||
| HttpClients.custom().addRequestInterceptorFirst(interceptor).build(); | ||
| ApiClient apiClient = new ApiClient(httpClient); | ||
| apiClient.setBasePath(consoleUrl); | ||
| api = new DefaultApi(apiClient); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
I'd like to reuse the existing java-sdk-common.http package for this rather than creating another HttpClient
There was a problem hiding this comment.
The HttpClient you created is not compatible with the generated client as this one relies on the selected http client framework (apache in this case).
This is why I added the AuthenticationInterceptor.
There was a problem hiding this comment.
I understand that your own http client helps us being independent of any http client framework, however the amount of code required to bind our implementation against a framework is REALLY limited (like 1 class with 10 loc)
|
@1nb0und (and maybe @berndruecker ): Maybe my 2 cents for generated client vs. implemented client (and forget what I wrote above, I wrapped my head around this for a while): As an API is implemented API-first (define open api spec, generate server stub and implement it), there is a revisioned resource openapi.json available to work with. Here, a generated client makes sense. If however, the API is implemented impl-first (write server stub, generate open api spec at runtime), there is no real resource available to implement against. Here, we could rely on an implemented client. wdyt? |
jonathanlukas
requested review from
sbuettner
and removed request for
1nb0und
jonathanlukas
force-pushed
the
feature/console-client
branch
from
4b2e550 to
d426a22
Compare
This PR will add a generated console client, wrap it with a handsome api and also add it to the spring boot starter.
It is based on https://github.com/camunda-community-hub/camunda-console-client-java which will be archived after this PR is merged.