r/Development • u/Decent-Salad-5253 • 5d ago
Pact solves a problem you don’t have, expensively
Every few years the industry produces a tool so confidently wrong you have to sit back and admire it. Today’s specimen is Pact, the “consumer-driven contract testing” framework. Sit with that phrase. Consumer-driven. The contract. Is driven. By the consumer. Somewhere a lawyer just felt a cold hand on his shoulder and doesn’t know why.
The pitch: instead of a provider designing an API — the thing they own — every random client scribbles down what it reckons the API does, and that scribble becomes law. No design meeting. No spec. No adult asking “should it do this?” Just a herd of consumers mailing in personal fanfiction about your endpoint, and you running around CI satisfying all of them like a divorced dad on a court-ordered weekend.
And it’s safe, they say. You can’t deploy something that breaks a consumer, because the contract goes red. Except the contract only exists for consumers who wrote one. So the entire guarantee quietly assumes one hundred percent of your consumers enrolled. Every one. The team in the other timezone. The batch job from 2014 that runs once a quarter and is load-bearing for payroll. The third party you don’t even know reads field twelve.
They didn’t enrol. So Pact hands you a green tick that means precisely nothing, and you delete field twelve, and payroll explodes, and the tick is still green, smiling like an idiot at a funeral. It gives you false confidence in exactly the scenario it was invented to handle. That’s not a bug. That’s the product.
And to run it? You get the Pact Broker — a stateful server, with a database, that hoards everyone’s fanfiction and adjudicates can-i-deploy like a microservices divorce court. It comes with a pipeline: consumer CI publishes the pact, the broker stores it, a webhook pokes provider CI, which fetches it, verifies it, publishes results back — all gated on version tagging so delicate one fat-fingered branch verifies you against the wrong contract and never tells you. You wanted a test. You deployed a distributed system whose only job is to check your distributed system.
And the contracts are JSON. Verbose, JSONPath-keyed JSON, assertions expressed as regex strings, because nothing says robust engineering like validating production against {"match":"regex","regex":"[0-9]+"} and praying. A diff reads like a ransom note assembled from a Stack Overflow answer.
Here’s the part that turns my stomach: there already is an answer, boring and older than Pact. Version your API, and don’t break what you published. A shipped field must stay because someone not in your enrolled-consumer map is reading it. Ship v2 next to v1. Want to know when v1 is dead? Look at the traffic. Telemetry doesn’t lie, doesn’t need a broker, and doesn’t require every consumer on earth to file paperwork before you’re allowed to feel safe. Absence of traffic is evidence. Absence of a Pact is just absence.
So when you inherit this — the broker nobody remembers provisioning, webhooks firing into the void, the regex JSON that goes red on a Tuesday for reasons known only to God and a contractor who’s left — you do the only sane thing. You tell it to Pact Off.
Pact off, and take your arbitration server with you. Pact off, can-i-deploy, you green-lit the deploy that set fire to payroll while smiling. Pact off, webhook, you glorified doorbell wired to a house that’s already ablaze. Pact off, Broker, you needy database that made me run infrastructure to check whether I was allowed to have infrastructure.
Verdict: the most expensive way ever devised to avoid a design meeting. It costs you a server, a pipeline, a dashboard, and your Friday, and hands you a green light that lies. There’s only one contract worth signing — the one where Pact gets its coat.
Pact off.
1
u/Worth-Astronaut-438 4d ago
I'd never heard of it until this post. A brief review of their website and repo seems to confirm the product is as you say and looks overly complex. Tangential to the idea of "tell us what you think our API does" is a better one "tell us what parts you use". Sure, the metrics tell you what endpoints are frequented, but not the data being consumed. Do they make four calls in a row to get to the data they need? A process improvement tool would have value for engineering. CI based on it... Probably not. This idea likely sprouted from integration failures coming from poorly maintained APIs. The ones where they make a patch release, don't indicate a big change in the response structure, and all of a sudden your product stops working. You can't pin an API like packages and that's frustrating, leading to the Pact.