Consumer driven contracts (CDC) are like TDD applied to the API. It’s especially important in the world of microservices. Since it’s driven by consumers, it’s much more user friendly. Of course microservices are really cool, but most people do not take into consideration plenty of potential obstacles that should be tackled. Then instead of frequent, fully automated deploys via a delivery pipeline, you might end up in an asylum due to frequent mental breakdowns caused by production disasters. We will write a system using the CDC approach together with Spring Boot, Spring Cloud Contract verifier. I'll show you how easy it is to write applications that have a consumer driven API and that will allow a developer to speed up the time of writing his better quality software.

1. Consumer Driven Contracts
and Your Microservice
Architecture
Marcin Grzejszczak, Pivotal
@mgrzejszczak

2. Spring Cloud developer at Spring Cloud (Pivotal)
Working mostly on Spring Cloud Sleuth
and Spring Cloud Contract
Automation freak
About me
Twitter: @mgrzejszczak
Blog: http://toomuchcoding.com

3. Introduction
Demo
Summary
Agenda

4. ● Producer
○ service that exposes an API
● Consumer
○ service that consumes the API of the producer
● Contract
○ agreement between producer and consumer how the API will look like
● Consumer Driven Contracts
○ approach where the consumer drives the changes of the API of the producer
Introduction

5. ● Stub validity & reusability in the integration tests
● Nice API creation
Introduction
What problems are we trying to solve?

6. Introduction
Typical situation
HTTP
CONSUMER PRODUCER

7. Introduction
How to write a test for it?
HTTP
CONSUMER PRODUCER

8. Introduction
Stub validity & reusability
WE’RE ON THE CONSUMER SIDE!!
CONSUMER OWNS THE STUB
DEFINITIONS

9. Introduction
Stub validity & reusability

10. Introduction
Stub validity & reusability
10

11. Introduction
Stub validity & reusability
11

12. Introduction
Stub validity & reusability
12

13. Introduction
Stub validity & reusability
13

14. ● My tests fail cause I’m shooting a request at a non existant URL
● I rewrote all my code to work with the new URL
● The unit and integration tests pass
● Now we deploy to an environment
where real integrations will take place...
Introduction
So now what?

15. Introduction
Ooops...

16. Stubs that were used in the build phase have nothing to do with the real API!!
Introduction
What went wrong?
HTTP
CONSUMER PRODUCER
TEST
OK
HTTP
CONSUMER PRODUCER
REALITY
WAT?!

17. ● Stubs reside with the consumer
● Consumer controls the stubbing process
● How are you sure that the stubs are valid?
● What if other teams want to reuse those stubs?
Introduction
Stub validity & reusability

18. ● It’s the consumer that uses the API
● Consumers should take part in the creation of the API of the producer
● The producer’s API change should be driven by consumers
Introduction
Nice API creation

19. Introduction
Nice API creation - no cooperation results

20. Introduction
Nice API creation - no cooperation results

21. Demo
Potential answer
Spring Cloud Contract

22. ● Consumer
○ service that gets beer requests
○ has to ask another service if the client can get the beer
● Producer
○ service that checks if the client is old enough to buy beer
● Feature
○ if the user is too young - the beer will not be sold
○ otherwise the beer will be granted
Demo
What are we going to code?

23. Introduction
What are we going to code?
I’m 22 give me a beer
CONSUMER PRODUCER
There you go!
Can he get the beer?
Yes!

24. Introduction
What are we going to code?
I’m 17 give me a beer
CONSUMER PRODUCER
Get lost!
Can he get the beer?
No!

25. Introduction
What are we going to code?
BLACK TERMINAL
BLACK IDE
CONSUMER
WHITE TERMINAL
WHITE IDE
PRODUCER

26. Demo
DEMO

27. Summary
Consumer’s offline
work
Consumer Phase 1 Consumer Phase 2
Consumer’s switching
to online
Producer phase
Producer’s
implementing the
feature

28. Summary
Consumer flow 1
• starts TDD - writes the test for the feature
• clones producer code to change the API locally
• in the cloned producer code converts contracts into stubs and installs
them locally
• in the consumer code turns Stub Runner to offline mode
• configures Stub Runner to download stubs of the producer
• red - green - refactor on the API and tests
• repeats the process until the tests are green and API acceptable
• files a PR to the producer with the contract proposal

29. Summary
Producer flow
• takes over the PR
• writes the missing implementation that will make the autogenerated tests pass
• merges PR and deploys the JARs with the app and the stubs

30. Summary
Consumer flow 2
• switches off the Stub Runner’s offline mode once the producer uploads the
stubs
• configure Stub Runner by providing the URL to a repo with stubs
• will have its test broken if the producer makes any breaking changes of the API

31. With Spring Cloud Contract and Consumer Driven Contracts:
● we’ve created an API that suits the consumer and the producer
● expectations were defined by readable contracts
● expectations were tested against the producer
● producer stubs can be reused by consumers
● starting and setting stubs is fully automated
Summary

32. Why use Spring Cloud Contract Verifier?
● Possibility to do CDC with messaging
● Clear and easy to use, statically typed DSL
● Automatic generation of tests from the defined Contract
● Stub Runner functionality - the stubs are automatically downloaded at runtime from
Nexus / Artifactory
● Spring Cloud integration - no discovery service is needed for integration tests
● Integration with Cloud Foundry - Stub Runner Boot
● Possibility to keep all contracts in a single repo
Summary

33. Demo

34. Spring Cloud Contract repo
Spring Cloud Contract documentation
Spring Cloud Contract Gitter
Producer sample
Client sample
LINKS

35. Thank you!
Marcin Grzejszczak
Pivotal
mgrzejszczak@pivotal.io
mgrzejszczak