Згенерувала контракт API із самої бази даних

Ситуація. Фронтенд і бекенд розвиваються кожен у своєму темпі, і їхні уявлення про тіло запиту можуть непомітно розійтися. Зазвичай про це дізнаються з помилки 422 у браузері — вже після того, як розбіжність потрапила в продакшн, а це найдорожчий момент, щоб про неї дізнатися. Писати обидві сторони вручну за одним документом — не вихід: розбіжність просто переходить до того, хто забув перечитати документ.

Завдання. Обидві сторони мали генеруватися з одного джерела, а не узгоджуватися між двома, і кожен крок цієї генерації мав перевірятися, а не братися на віру.

Дія. Ланцюг починається з бази даних і тягнеться назовні. Схема та її функції визначають структури даних; типи Go визначають API; Huma формує з них опис OpenAPI; з цього опису генерується типізований клієнт на TypeScript обсягом 44 076 рядків; поряд із ним генерується 61 mock‑обробник, тож власні тести фронтенду працюють із реальним контрактом, а не з фікстурою, написаною вручну; а обмеження, які UI накладає на форму, беруться з того самого джерела, а не передруковуються у валідатор. Кожен перехід має запобіжник. Перевірка контракту в CI порівнює те, що надсилає фронтенд, із тим, чого чекає API, і в разі розбіжності зупиняє збірку, а під нею працює перевірка схеми, яка звіряє реальні структури, а не їхній опис. Вона свідомо охоплює місця, де розбіжності люблять ховатися: необов’язкові поля тіла запиту, де плутають «відсутнє» й «null», та enum‑параметри запиту, де дві сторони можуть непомітно розійтися щодо допустимих значень.

Результат. Поле не може змінитися лише з одного боку — це виявляється на першому ж переході, у збірці, за кілька хвилин після зміни. Так зник клас помилок, що раз у раз поверталися й по‑справжньому дратували: на рев’ю коду їх не видно, а проявляються вони лише під час виконання. Ціна — крок генерації посеред усього процесу: генерувати все наново — морока, а ланцюгу можна довіряти не більше, ніж його найменш захищеній ланці, тому запобіжник має кожен перехід.