> ## Content Index
> Fetch the complete content index at: https://stalin-pereira.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Implementing Pact to Prevent Breaking API Changes
- URL: https://stalin-pereira.com/implementing-pact-to-prevent-breaking-api-changes/
- Published: 2025-12-30T10:41:00.000Z
- Updated: 2026-10-16T19:08:16.000Z
- Description: Preventing frontend breaks when backend APIs change
- Author: Stalin Pereira
- Tags: Testing

**Stop Breaking The Frontend**

Why your app breaks even when all the unit tests pass.

## The 'Drive-Thru' Disaster

Imagine a restaurant changing the menu without updating the board.

- **The Order** — You order a '#1 Combo' expecting a Burger.
- **The Kitchen** — The kitchen silently changed '#1' to a Salad yesterday.
- **The Crash** — You open the bag, panic ensues, and lunch is ruined.

## This is Your API Architecture

The Backend changed the shape of the data, but the Frontend didn't get the memo.

- **The Expectation** — Frontend expects: { "userId": 123 }
- **The Reality** — Backend sends: { "id": 123 }
- **The Result** — Cannot read property 'userId' of undefined. White screen of death.

## Why Traditional Testing Fails

We usually rely on two extremes, and both have gaps.

- **Unit Tests (Mocks)** — Fast, but you are mocking assumptions. If the assumption is wrong, the test lies.
- **E2E Tests (Selenium/Cypress)** — They catch real bugs but are slow, flaky, and expensive to run on every commit.

## Enter: Contract Testing (Pact)

A legally binding agreement between Frontend and Backend.

- **The Concept** — Define the API shape *before* you code it.
- **The Guardrail** — If the Backend breaks the contract, their build fails. Not the Frontend's.

## How It Works: Consumer-Driven

The Frontend (Consumer) sets the rules.

- **Define** — The Frontend writes a test: 'I expect a user object with a generic id field'.
- **Generate** — This test generates a 'Pact File' (a JSON contract).
- **Share** — This file is sent to a shared server (Pact Broker).

## The Provider Verification

The Backend (Provider) must sign the contract.

- **Fetch** — The Backend CI downloads the Pact file.
- **Replay** — Pact automatically sends the requests defined in the file to the running Backend.
- **Verify** — If the Backend response matches the file, the build passes.

## The 'Pact Broker' is Key

The central source of truth for your API versions.

- **The Matrix** — It knows which version of Frontend is compatible with which version of Backend.
- **Can I Deploy?** — The CLI tool checks: 'Is it safe to deploy this Backend to Production?'

## The Old Way vs The Pact Way

Moving from hope to certainty.

- **Old Way** — Backend changes code -> Deploys -> Frontend breaks in Prod -> Hotfix panic.
- **Pact Way** — Backend changes code -> Local Build Fails (Contract Violation) -> Fix before commit.

## Architectural Benefits

Why Architects love this pattern.

- **Decoupling** — Teams can work independently without needing a live environment of the other service.
- **Speed** — Tests run in milliseconds (unlike E2E) because they don't need a full browser.
- **Documentation** — The Pact file *is* the documentation. It can never be out of date.

## The ROI for Stakeholders

Why you should invest time in setting this up.

- **Zero Surprises** — Eliminates the 'Integration Hell' usually seen the day before release.
- **Faster Debugging** — You know exactly which field caused the break, instantly.
- **Confidence** — Deploy on Fridays without fear.

## Summary: Trust, but Verify

Communication via code, not just Slack messages.

- **Contracts** — Define expectations explicitly.
- **Broker** — Manage compatibility versions centrally.
- **Peace** — Frontend and Backend teams stop blaming each other.

---

How many times did an API change break your UI this week?