In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down
* Provider and consumer integrations break when their understanding of the API endpoints are out of sync
* Working integrations break when the API developer makes a change without informing the consumer
* Development and testing slow down when the consumer depends on the provider API running in a staging environment:
** The network may be down
** The environment hosting the API may be down
** The staging API may crash, or may not even be started
** Development can be delayed if the staging API is not kept up-to-date
** API changes can come in at the last minute, resulting in breakage on the consumer side
** The provider API may break backward compatibility, resulting in breakage on the consumer
Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:
1. Kept up-to-date and acts as a single source of truth
2. Used for service virtualisation, keeping consumers in sync with the contract
3. Run as tests against the provider API to validate it's request and response type definitions
4. Tightly integrated with CI
5. Capable of pinpointing any backwards-incompatible changes to the contract
6. This is Contract Driven Development, and it heralds the Death of Integration Hell.
This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Qontract: https://qontract.run/
Contract Driven Development: The Death of Integration Hell
1. Contract Driven Development
The Death of Integration Hell 👿
Naresh Jain (@nashjain)
https://xnsio.com
Release under CC by Naresh Jain @ Xnsio 1
2. Micro-Frontends Micro-Services
Logical E-Com Application Architecture
External Dependencies
Payment Service
Payment Gateways
Authentication
Payment
Elastic
Search
DB
Inventory & Warehouse
Management Systems
Product Catalog
Service
Product Listing
Order Management
Service
Cart
DB
APIGateway
Release under CC by Naresh Jain @ Xnsio 2
3. Common SITCommon SIT
Current State of Testing in Competitor’s Org
PCS
OMS
PS
CS
IS
SS
External Services
1 2 3
Pre-Prod
PCS
OMS
PS
CS
IS
SS
1 2 3
API Testing
Workflow Testing
E2E Functional Testing Business Acceptance
E-Com Store Dev
Services
PCS OMS PS
Warehouse MS Dev
Services
CS IS SS 1 2 3
Legend
Unstable / Down
Integration Issue
Blocked
UnitTesting–Local
Prod
Release under CC by Naresh Jain @ Xnsio 3
5. Project B EATWarehouse MS EATWarehouse MS Dev
Services
E-Com Store Dev
Services
Early Feedback in a Controlled Env
Common SIT
PCS OMS PS
CS IS SS
PCS
OMS
PS
CS
IS
SS
1 2 3
External Services
1 2 3
E-Com Store EAT
PCS OMS PS
CS IS SS
Stubbed Dependencies
Stubbed Dependencies
API Testing Workflow Testing E2E Functional Testing
Shift Left
Legend
Unstable / Down
Integration Issue
Blocked
To Pre-Prod
Workflow Testing
Release under CC by Naresh Jain @ Xnsio 19
6. OMS PCSConnections Tested –
1. Between Internal and
External Services
2. Between internal
services
3. Between internal units /
modules within each
service
PaymentCart
Product
ListingSystem
Tests
Orders
Controller
Order
Repository
Product
Repository
Products
Controller
SIT
PaymentCartOMS
Orders
Controller
Order
Repository
PCS
Product
Repository
Products
Controller
Eg: Mockito Eg: Moq Eg: Jest
Unit Tests
1. Units / Modules Tested in Isolation
2. System Under Test – Modules 1, 2, 3 and 4
3. Dependencies stubbed with Mock Objects like Mockito, etc.
Connections
Tested –
None
Product
Listing
Local
Application Test Pyramid
Contractual Stubs
PGPCS
OMS
Orders
Controller
Order
Repository
Contractual Stubs
DB
PCS
PCS
Product
Repository
Products
Controller
Contractual Stubs
OMS
Elastic
Search
Component / Service Tests
1. Each Microservice (OMS & PCS) and
Micro-frontend (Cart & Payment) tested
in Isolation
2. Dependencies (External and Internal)
stubbed
3. Negative Path Testing by simulating
internal and external dependency errors
Connections Tested
–
Between internal
units / modules
within each
service/component
PaymentCart
Product
Listing
Dev
Auth
OMS PCS
Application Tests
Only External
Dependencies are
Stubbed
Connections Tested –
1. Between internal
services
2. Between internal
units / modules
within each service
Contractual Stubs
PG
PaymentCart
Product
Listing
Orders
Controller
Order
Repository
Product
Repository
Products
Controller
EAT
Auth
Payment
Gateway
Payment
Gateway
(PG)
Authentication
External Dependencies
Contract Testing - Turn your contracts into executable specifications
Micro FrontendsMicro Services
OMS – Order Management Service | PCS – Product Catalogue ServiceRelease under CC by Naresh Jain @ Xnsio 20
7. Production
Shadow Mode
Tests
Product Test Pyramid
SIT
EAT
Dev
Local
Application
Tests
Component /
Service Test
Unit Tests
System
Tests
Application 2
Application
Tests
Component /
Service Test
Unit Tests
System
Tests
Application 1
Pre-Prod User Acceptance Testing
Performance Testing
Product
Release under CC by Naresh Jain @ Xnsio 21
11. OMS PCSConnections Tested –
1. Between Internal and
External Services
2. Between internal
services
3. Between internal units /
modules within each
service
PaymentCart
Product
ListingSystem
Tests
Orders
Controller
Order
Repository
Product
Repository
Products
Controller
SIT
PaymentCartOMS
Orders
Controller
Order
Repository
PCS
Product
Repository
Products
Controller
Eg: Mockito Eg: Moq Eg: Jest
Unit Tests
1. Units / Modules Tested in Isolation
2. System Under Test – Modules 1, 2, 3 and 4
3. Dependencies stubbed with Mock Objects like Mockito, etc.
Connections
Tested –
None
Product
Listing
Local
Application Test Pyramid
Contractual Stubs
PGPCS
OMS
Orders
Controller
Order
Repository
Contractual Stubs
DB
PCS
PCS
Product
Repository
Products
Controller
Contractual Stubs
OMS
Elastic
Search
Component / Service Tests
1. Each Microservice (OMS & PCS) and
Micro-frontend (Cart & Payment) tested
in Isolation
2. Dependencies (External and Internal)
stubbed
3. Negative Path Testing by simulating
internal and external dependency errors
Connections Tested
–
Between internal
units / modules
within each
service/component
PaymentCart
Product
Listing
Dev
Auth
OMS PCS
Application Tests
Only External
Dependencies are
Stubbed
Connections Tested –
1. Between internal
services
2. Between internal
units / modules
within each service
Contractual Stubs
PG
PaymentCart
Product
Listing
Orders
Controller
Order
Repository
Product
Repository
Products
Controller
EAT
Auth
Payment
Gateway
Payment
Gateway
(PG)
Authentication
External Dependencies
Contract Testing - Turn your contracts into executable specifications
Micro FrontendsMicro Services
OMS – Order Management Service | PCS – Product Catalogue ServiceRelease under CC by Naresh Jain @ Xnsio 25
12. Contract Driven Development
Collaboratively Design and Independently Deploy MicroServices & MicroFrontends
Release under CC by Naresh Jain @ Xnsio 26
Contract Testing - Turn your contracts into executable specifications
14. Contract in central Repo
Contracts are executable specs which are
version controlled just like code
Release under CC by Naresh Jain @ Xnsio 28
15. Contract as Test
Providers runs these specs as
contract tests against their service
Release under CC by Naresh Jain @ Xnsio 29
16. Contract for Intelligent
Service Virtualisation
Consumers runs these specs as stubs
which validate their expectations
Release under CC by Naresh Jain @ Xnsio 30
17. Wrapping up
3 Key Takeaways…
Release under CC by Naresh Jain @ Xnsio 31
18. Takeaway 1: Hyper Collaborate
Architect
Consumer
Dev
Provider
Dev
QA
• Collaboratively design the API over a contract
• Communicate with a common language
Release under CC by Naresh Jain @ Xnsio 32
19. Takeaway 2: Shift Left
Consumer Provider
Stub Test
• Identify integration issues early
• local development environment
• CI
• Develop with ease
CI Pipeline Environment
Release under CC by Naresh Jain @ Xnsio 33
Contract
20. Takeaway 3: Deploy With Confidence
• Deploy independently, with confidence
• Bye-bye, Integration Hell!
Higher Environment
Release under CC by Naresh Jain @ Xnsio 34