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.