Получали ли вы готовую OpenAPI спецификацию и переносили из нее типы и методы

Что проверяют

Работали ли вы с контрактом как с источником правды или переписывали типы руками. За вопросом стоит понимание процесса: откуда берётся спецификация, что происходит при её изменении и кто чинит расхождение с реальным ответом сервера.

Как отвечать

Описывайте схему работы, а не сам факт:

• где лежит спецификация: в репозитории бэкенда, в общем пакете или отдаётся по адресу самого сервиса;
• чем генерируете: openapi-typescript, если нужны только типы, orval или openapi-generator, если нужен ещё и клиент с хуками запросов;
• когда запускается генерация: командой в package.json и проверкой в CI, чтобы расхождение сгенерированного кода со спецификацией ломало сборку;
• что сверху: тонкая обёртка с авторизацией, обработкой ошибок и отменой запросов, чтобы сгенерированный код не приходилось трогать.

Обязательно скажите про время выполнения. Типы существуют только на этапе сборки, и если сервер пришлёт не то, что обещал, приложение сломается уже у пользователя. Поэтому на границе полезна проверка ответа схемой, хотя бы для критичных экранов. Расскажите и про то, как ловите ломающие изменения: обновили спецификацию, перегенерировали, увидели разницу в типах и красную компиляцию раньше пользователя.

Где спотыкаются

Считают, что сгенерированные типы гарантируют корректность данных. Это обещание бэкенда, а не проверка: при несовпадении ошибки не будет, будет undefined в неожиданном месте.

Правят сгенерированный файл руками, потому что в спецификации ошибка. Следующая генерация затирает правку, баг возвращается, и чинить его будет уже другой человек. Ошибку исправляют в спецификации.

Тащат генератор с полным клиентом в проект, где уже есть свой слой запросов. Получаются два способа ходить в сеть, два набора перехватчиков и разная обработка ошибок. Когда слой запросов уже есть, генерируют только типы.