Har bygget en request‑schema‑valideringskontrakt med automatiserede guards, der fanger uoverensstemmelser i payloads mellem frontend og backend, før de når produktion.

Situation. Frontend og backend bevæger sig i deres eget tempo, og deres antagelser om en request‑payload kan glide fra hinanden, uden at nogen bemærker det. Måden, man som regel opdager det på, er et 422 i browseren — efter uoverensstemmelsen allerede er udgivet, hvilket er det dyreste tidspunkt at få det at vide på.

Opgave. Målet var de uoverensstemmelser fanget af pipelinen, automatisk, før de kunne nå en bruger.

Handling. Et kontrakt‑tjek kører i CI — api‑contract‑check.sh — som sammenligner det, frontenden sender, med det, API’et faktisk forventer, og får buildet til at fejle ved enhver afvigelse. Der er en schema‑probe under det, som tjekker de rigtige former frem for en beskrivelse af dem. Det dækker bevidst de tilfælde, hvor drift kan lide at gemme sig: valgfrie body‑felter, hvor “mangler” og “null” bliver forvekslet, og query‑parameter‑enums, hvor de to sider stille og roligt kan være uenige om de tilladte værdier. I stedet for at stole på, at folk holder frontend og backend i takt i hånden, gør tjekket det.

Resultat. De to halvdele forbliver i takt. En payload‑uoverensstemmelse får et build til at fejle i stedet for at overraske en bruger, hvilket tog en tilbagevendende og oprigtigt irriterende klasse af fejl af bordet — den slags, der er usynlig i code review og først dukker op i runtime. Og fordi det kører i pipelinen, får en bidragyder hurtigt besked, når en ændring ville bryde kontrakten, mens rettelsen stadig er billig.