Post FastAPI ломают не роуты, а границы между схемой, логикой и БД

FastAPI ломают не роуты, а границы между схемой, логикой и БД За неделю в репах: один и тот же набор проблем повторяется почти в каждом сервисе на FastAPI. Путь красивый, а внутри handler делает всё сразу: валидирует, ходит в БД, собирает ответ, ловит исключения. Такой код быстро растёт, а потом любое изменение превращается в цепочку правок по всему проекту. Рабочая схема проще: — router принимает запрос и отдаёт его в сервис; — service держит бизнес-логику; — repository/DAO прячет SQLAlchemy, Redis или внешнее API; — pydantic-схемы отвечают только за контракт входа и выхода. Есть наблюдение которое стоит проверить: если в endpoint больше 20-30 строк, он уже просит разбиения. Второй красный флаг — когда тест на один маршрут требует поднять половину приложения. Это обычно значит, что зависимости зашиты не через DI, а напрямую. Не смешивайте async и blocking без явного контроля. Любой requests, тяжелый файл-IO или CPU-задача внутри async-обработчика может убить конкурентность. Для таких мест нужен отдельный поток, воркер или вынос в очередь. И ещё: не тащите ORM-модели наружу как response_model, если потом придётся объяснять, почему утекли лишние поля. В FastAPI лучше всего живут тонкие роуты, явные схемы и сервисы, которые можно тестировать без HTTP.