FastAPI ломают не роуты, а мелкие решения вокруг зависимостей и схем

FastAPI ломают не роуты, а мелкие решения вокруг зависимостей и схем

Чаще всего проект начинает «тормозить» не на HTTP-слое, а на том, как собраны зависимости и где живёт бизнес-логика. Если в каждом роуте есть доступ к БД, проверка прав, парсинг и маппинг DTO, код быстро превращается в набор копипасты.

Держите границы жёстче:
— роут отвечает за вход и выход;
— сервис — за сценарий;
— репозиторий — за запросы;
— pydantic-модели — только для контракта, не для правил.

Ещё одна частая ошибка — тащить sync-код в async-эндпоинты без понимания блокировок. Если внутри запроса есть тяжёлый I/O, внешний API или файловые операции, они должны быть вынесены отдельно, иначе один медленный вызов начнёт душить весь воркер.

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

Если FastAPI в проекте «стал сложным», обычно виноват не фреймворк, а отсутствие границ. Чем раньше разнести роуты, сервисы и доступ к данным, тем дешевле будет каждый следующий endpoint.