FastAPI ломается не на роутинге, а на границе между схемой, БД и фоном

FastAPI ломается не на роутинге, а на границе между схемой, БД и фоном

За неделю в репах чаще всего всплывает один и тот же набор ошибок:
— в Pydantic-модели разрешили лишнее, а потом удивляются «грязным» payload;
— async-эндпоинт зовёт sync ORM или блокирующий клиент и начинает душить event loop;
— фоновые задачи используют request-state, который уже умер после ответа.

Проверь три границы: вход, работу и выход. На входе держи строгие модели и явное преобразование типов. Внутри не смешивай async-код с тяжёлыми sync-вызовами без обёрток. На выходе не возвращай «как получилось» — сериализуй через response_model или отдельный DTO. Иначе один и тот же объект начнёт вести себя по-разному в API, в тестах и в задаче.

Ещё одна типовая ловушка — dependency injection как склад всего подряд. Когда в зависимость пихают и конфиг, и клиента БД, и кэш, и логику авторизации, тесты становятся хрупкими, а переиспользование почти исчезает. Лучше держать зависимости узкими: один объект — одна ответственность.

Если FastAPI кажется «простым», это обычно значит, что границы пока не проверяли нагрузкой и чужими руками. Сначала режьте слой входа и слой доступа к данным, потом уже ускоряйте код внутри.