Generating http-based client from contract

[henryyonathan90]

Currently many consumer still need to manually define feign client (or with any other means) to call the producer.
With the contract already defined, producer should be able to automatically generate feign client with common configuration and it can be used by all of its consumer.

So the point is:

1. Producer generate feign client based on contract, it will be in form of jar, have common configuration but it can be override with properties value.
2. Each consumer can add dependency to artifact in point 1 to use the auto-generated feign-client and only add additional properties if they need custom configuration for the client.

[marcingrzejszczak]

Hi! That's an extremely interesting issue. Actually I would change it to generation of clients as such. @jkubrynski has either mentioned this a long time ago or even filed an issue about this.

So the idea would be that a snippet of concrete client side call would be generated. RestTemplate, Feign, whatever. That should be of course pluggable.

I think I'd prefer to generate it as a snippet rather than code, but with the pluggable architecture of this solution, one could also produce concrete code I guess.

Do I understand your issue correctly? :)

cc @jkubrynski @OlgaMaciaszek @fitzoh @TYsewyn

[henryyonathan90]

Hi Marc. Yes correct, the main point is generation of the client with pluggable architecture. I've changed the title to reflect this.

Taking feign as example, I think we can easily generate the concrete code and include it in component scan. But I am not really sure how to do it with code snippet.

As long as it does help the consumer to easily consume the producer both way should be ok for me :)

[fitzoh]

Cool idea... @cah-markrave I think you might have wanted something kind of like this

[TYsewyn]

Although it’s an interesting idea, I’m not sure if that’s something that you want.
You’ll be creating a hard link between 2 applications.
Whenever you execute a build you’ll create a new jar, this in turn needs to be added as a dependency in your consumer’s application(s).
Following this setup you’ll create a lot of overhead and a lot of maintenance if consumers aren’t upgrading to the latest version of your jar.
IMO this goes against all rules of loosely coupled services and a microservices architecture (if you’re doing that).
It does remind me of old RMI and Corba calls, and it looks just like the misusage of Swagger documentation.

[henryyonathan90]

Hmm, okay I understand your concern.
Adding the generated jar as dependency does give tight coupling between consumer and producer, which is against microservices architecture.

And besides, now that you mentioned Swagger, basically this idea have the same concept with swagger codegen that is to generate client sdk based on api spec.

I am thinking of integration between cloud-contract with swagger OAS and stumbled upon this issue #136. Referring to @marcingrzejszczak statement "it turns out that schema based solutions are not really suitable as input for Spring Cloud Contract", is there any possibility to do the opposite? (generating OAS from contract)

Maintaining both contract and OAS doesn't seems a good idea..

[TYsewyn]

Well, I would recommend you to generate your documentation using Spring REST Docs and go from there. I know there is a possibility to convert to Swagger/Open API.
It does make sense to generate snippets mainly for documentation purposes.
So that could be added to SCC, which in turn would be picked up by Spring REST Docs.

Will that cover your issue?

EDIT: Found the issue which tracks the OAS conversion, check out spring-projects/spring-restdocs#213

[marcingrzejszczak]

If I get you @TYsewyn , you're saying to fix this issue - #613 , generate rest docs tests from contracts. That way we would start getting documentation out of the box?

[TYsewyn]

Exactly! I think that will cover a couple of issues at the same time.
We can generate snippets which can be included in an adoc document and use those snippets/that documentation to generate eg. curl commands, which in turn can be used to generate a Swagger JSON file/playground.

WDYT?

[marcingrzejszczak]

I agree! That's a very good idea

[henryyonathan90]

Cool, that would indeed connect all the pieces together and solve the problem.

So CMIIW, to summarize the solution will be:
-create contract as the top source
-generate restdocs from contract #613
-generate OpenAPI spec from restdocs spring-projects/spring-restdocs#213
-generate client sdk from OpenAPI using swagger-codegen

Well, I will try to look into restdocs first since I am not really quite familiar with it. Hopefully will be able to contribute something :)

[marcingrzejszczak]

Example of doing what @henryyonathan90 suggested - https://github.com/spring-cloud-samples/spring-cloud-contract-samples/pull/29/files