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

FastAPI ломают не роуты, а мелкие решения вокруг зависимостей и схем Чаще всего проект начинает «тормозить» не на HTTP-слое, а на том, как собраны зависимости и где живёт бизнес-логика. Если в каждом роуте есть доступ к БД, проверка прав, парсинг и маппинг DTO, код быстро превращается в набор копипасты. Держите границы жёстче: — роут отвечает за вход и выход; — сервис — за сценарий; — репозиторий — за запросы; — pydantic-модели — только для контракта, не для правил. Ещё одна частая ошибка — тащить sync-код в async-эндпоинты без понимания блокировок. Если внутри запроса есть тяжёлый I/O, внешний API или файловые операции, они должны быть вынесены отдельно, иначе один медленный вызов начнёт душить весь воркер. Для поддерживаемости полезно сразу договориться о трёх вещах: единый формат ошибок, отдельные слои для тестов и короткие зависимости без скрытых побочных эффектов. Чем меньше магии в Depends, тем проще читать проект через полгода и не ловить сюрпризы в проде. Если FastAPI в проекте «стал сложным», обычно виноват не фреймворк, а отсутствие границ. Чем раньше разнести роуты, сервисы и доступ к данным, тем дешевле будет каждый следующий endpoint.