Pact’s Dependency Drag​: Why Consumer-Driven Contracts Don’t Support Parallel Development

Exploring the challenges and limitations of using Pact for contract testing in a microservices environment. 

In the domain of microservices, ensuring seamless communication between different services is paramount. This necessitates robust contract testing to ensure that APIs and their consumers are in sync. With an increasing number of organizations adopting microservices, tools like Pact—a consumer-driven contract testing framework—have gained popularity. However, this approach comes with its own set of challenges. This post investigates these challenges and explores the drawbacks of using Pact for contract testing. 

The Code-First Approach – Understanding Pact’s Framework 

Pact operates on a code-first approach. This means that the developers need to write the unit tests and code for API consumer classes first. Only then can the interactions be mocked using Pact’s Domain Specific Language (DSL). For instance, consider developing an Android application that interacts with a backend for front-end (BFF) service. The developer must first write the Android-specific API client class and its corresponding unit tests. The next step is to use Pact DSL to mock the API provider, aka the backend application. 

The Learning Curve 

The first significant hurdle faced by developers is the learning curve associated with Pact’s DSL. Not only do developers need to be adept at writing the application code, but they also must familiarize themselves with the intricacies of Pact DSL. This additional layer of complexity can slow down development, especially for teams new to contract testing tools. 

Managing the Pact Broker 

Centralized Management 

Once the interactions between the consumer and mocked providers are established, Pact generates a contract in the form of a JSON file. This file needs to be stored and managed in a central repository known as the Pact Broker. The Pact Broker orchestrates all the generated contract files, making them available for running contract tests against providers. 

Maintenance Concerns 

The central challenge with the Pact Broker is its maintenance. As an independent server, it needs constant upkeep to ensure it is operational. If the broker goes down, it can disrupt continuous integration (CI) pipelines and block crucial features from being deployed, presenting a significant risk to project timelines and stability. 

The Multiplier Effect with Multiple Consumers 

Diverse Consumer Expectations 

In a real-world scenario, a single API provider often serves multiple consumers. Each consumer, be it iOS, Android, or web applications, will generate its version of the Pact JSON, reflecting what the consumer expects from the provider. The ultimate contract for the BFF is thus an aggregate of all these consumer expectations, making the orchestration far more complex. 

Layered Complexity 

The backend for front-end application might depend on various other services, leading to intricate dependency chains. In such layered architectures, every service interaction has to be mocked and tested with Pact. The backend calls to domain services necessitate domain API mocks, which generate their contract JSON files. This cumulative build-up of Pact files from multiple services and consumers becomes overwhelmingly intricate. 

The Third-Party Dilemma – External Dependencies 

The complexity magnifies when services depend on external third-party APIs. These third-party services are beyond the control of the internal development teams. Convincing an external provider to adopt and test against Pact contracts is often impractical, if not impossible. This limits the efficacy of consumer-driven contracts when integrating with third parties. 

Duplication of Information – Dual Maintenance 

A significant operational challenge is the dual maintenance of OpenAPI specifications and Pact JSON files. OpenAPI is a widely accepted standard that many teams and third-party providers already use for API documentation and development. Introducing Pact JSON as an additional artifact results in duplicated information and fragmented sources of truth. This duplication can cause inconsistencies and outdated contracts, which can lead to integration issues. 

Conclusion 

Given the steep learning curve, operational complexities, maintenance overheads, and the necessity of managing multiple sources of truth, Pact presents several challenges for contract testing in microservices environments. While it offers a structured way to define and test consumer-provider interactions, its constraints make it less suitable for many real-world scenarios. This underscores the importance of weighing these challenges against the benefits before adopting a tool like Pact. Understanding these nuances can help teams make informed decisions that align with their operational dynamics and technical needs. 

Specmatic was developed to overcome these shortcomings and to empower developers with the tools to leverage Contract Driven Development and enable the efficient, accelerated and reliable parallel development of microservices. 

See also: Comparison: Specmatic vs Pact.io and Pactflow.io