Команда фронтенд-разработки внедрила типизированный слой мокирования API, который существует только в режиме разработки. Благодаря интерцепторам Axios и механизму tree-shaking в Vite, продакшн-бандл остается нетронутым. Инженеры получают данные привычными способами, пока ждут готовности эндпоинтов бэкенда, а затем просто переключают один флаг окружения, чтобы начать работу с реальным API.

Почему команде понадобился лучший способ мокирования

Фронтенд-разработчики заходят в тупик, когда маршрут бэкенда еще не готов. Быстрое решение — хардкод ответа внутри компонента или разбрасывание блоков if (process.env.NODE_ENV === 'development') по всему UI — позволяет приложению работать, но создает технический долг. Эти мок-объекты становятся частью логики компонента, повышают риск попадания фейковых данных в продакшн и усложняют чтение и тестирование кода.

Команда хотела вынести все моки за пределы дерева компонентов, внедрить контракт между фронтендом и бэкендом и гарантировать, что в продакшн-сборку не попадет ничего лишнего.

Трехэтапный процесс, которому следует команда

  1. Встреча по контракту — фронтенд- и бэкенд-инженеры садятся вместе и составляют список каждого запроса, его URL, метода и ожидаемой полезной нагрузки (payload).
  2. Типизированный контракт — они превращают этот список в интерфейс TypeScript, который становится единым источником истины для структур запросов и ответов.
  3. Подключение интерцептора — интерцептор Axios проверяет каждый исходящий запрос. Если URL совпадает с зарегистрированным моком, интерцептор возвращает мок-данные; в противном случае запрос отправляется на живой сервер.

Поскольку интерцептор — это единственное место, где живет логика моков, код компонентов остается неизменным. Разработчики продолжают использовать свои обычные хуки для получения данных — например, useQuery — не добавляя никакой условной логики.

Как избегается раздувание продакшн-сборки

Команда внедрила три уровня защиты, которые позволяют Rollup (бандлеру, используемому в Vite) полностью удалять код моков при сборке для продакшна:

  • import.meta.env.DEV принимает значение false в продакшн-сборке, поэтому весь модуль интерцептора исчезает во время tree-shaking.
  • Переменная MODE устанавливается в значение, отличное от test при запуске юнит-тестов, что позволяет отделить код, предназначенный только для тестов.
  • Кастомный флаг VITE_ENABLE_MSW по умолчанию равен false и должен быть явно включен для активации моков.

Когда все три условия ложны, реестр моков никогда не попадает в финальный бандл.

Организация файлов моков

Репозиторий следует структуре, ориентированной на фичи (feature-centric layout):

  • interfaces/ — содержит определения TypeScript, созданные на основе встречи по контракту.
  • scenarios.ts — содержит конкретные примеры успешных ответов и случаев ошибок для каждого эндпоинта.
  • devHandlers.ts — служит центральным реестром, который сопоставляет URL с данными сценариев и подключает интерцептор к Axios.

Небольшой скрипт генерации (scaffolding script) может создавать эти файлы автоматически: достаточно передать ему URL и соответствующий интерфейс, и он создаст файлы-заглушки и зарегистрирует мок. Скрипт находится вне пути продакшн-кода, поэтому он не влияет на размер бандла.

Чего добилась команда

  • Никаких моков внутри компонентов — все фейковые данные живут в выделенном слое, что сохраняет чистоту кода UI.
  • Сквозная типизация (end-to-end type safety) — мок-данные соответствуют тем же интерфейсам TypeScript, что и реальные ответы, поэтому несоответствия обнаруживаются на этапе компиляции.
  • Отсутствие веса в продакшне — tree-shaking полностью удаляет интерцептор и мок-данные, не увеличивая размер бандла.
  • Общие сценарии для разработки и тестирования — одни и те же определения моков используются как для локальной разработки, так и для автоматизированных тестов, что уменьшает дублирование.

Компромиссы и ограничения

Этот подход не заменяет реальный бэкенд. Если контракт мока разойдется с живым API, разработчики обнаружат несоответствие только после переключения флага окружения.

На что обратить внимание в будущем

  • Интеграция с инструментами —
  • Более широкое внедрение —
  • Мониторинг производительности —

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