I'm just starting with Consumer-Driven Contracts for our microservice setup, and as they are mainly Spring Boot apps natural choice is Spring Cloud Contract. But then comes the confusion. In all examples in docs contracts are defined on the producer side, and consumer retrieves them from maven repo. How it is consumer-driven if the producer defines them?
My understanding was that conceptually consumer defines them as its expectation from the producer for part of the API it uses. In addition to the previous question, is it possible with Spring Cloud Contract to define a contract on the consumer side and verify it on producers?
Thanks for this question. Yes, Spring Cloud Contract can be consumer-driven or producer driven.
The contract definitions can lay either with the producer or in an external repository. The concept of consumer-driven is not related to the fact where the contract are stored. It's related to the fact who creates them or actually who drives the change of those contracts. Another thing is whether each consumer can define a set of their own requirements. That means that one consumer can have different requirements than another one.
So in Spring Cloud Contract for the producer-driven approach, the producer just creates the contracts and it doesn't really care if different consumers use their API in a different way. The producer of the API creates e.g. 1 contract definition for all the consumers and it's the consumer's problem to align to that contract.
With consumer-driven contracts with Spring Cloud Contract, it's the consumer that suggests the changes and creates the contract definitions. The consumer sends a PR either to the producer team's repo or to a separate repo where all the contract definitions are stored. It's not the producer, but the consumer who does it. The consumer can, in the meantime, create the stubs locally without asking the producer for the permission, and prototype the API. Once the consumer has finished its work and of course talked with the producer team about the changes before, then a pull request can be sent with the suggested changes. Important thing to remember is that each consumer has their own folder with their requirements. E.g. if there are consumers example1 and example2 and there's a producer producer1 then under producer1's contract folder there will be 2 folders, one example1 and the second example2. Both will contain expectations for the particular consumer.
Then the producer takes the PR over and the verification happens on the producer side. The tests are generated. Once the implementation is written and tests are passing the stubs can be uploaded.
Finally, on the consumer side, the consumers can switch to start fetching the uploaded stubs to always get the fresh version of the stubs.
You can check a video of how full cycle of CDC is done here: https://www.youtube.com/watch?v=pDkC_00hhvA
Consumer Driven Contract tutorial: https://cloud-samples.spring.io/spring-cloud-contract-samples/tutorials/stubs_per_consumer.html
Producer Contract tutorial with contracts on the producer side: https://cloud-samples.spring.io/spring-cloud-contract-samples/tutorials/contracts_on_the_producer_side.html
Producer Contract tutorial with contracts in an external repo: https://cloud-samples.spring.io/spring-cloud-contract-samples/tutorials/contracts_external.html