<b>FastAPI ломают не роуты, а неправильные зависимости и валидация</b>

<b>FastAPI ломают не роуты, а неправильные зависимости и валидация</b>

За неделю в репах чаще всего всплывает одна и та же проблема: проект стартует быстро, а потом начинает тормозить на интеграциях. Причина обычно не в самом FastAPI, а в том, как собраны зависимости, схемы и фоновые задачи.

• Не тащите тяжёлую работу в endpoint. Всё, что ходит во внешние API, пишет файлы или собирает отчёты, уносите в очередь или background task.
• Не делайте pydantic-модели «на всё». Отдельно держите request, response и internal schema — иначе валидация превращается в кашу.
• Не смешивайте бизнес-логику с роутом. Endpoint должен принять данные, вызвать сервис и вернуть ответ, а не решать половину доменной задачи.

Есть наблюдение которое стоит проверить: большинство багов в FastAPI появляется не на async, а на границе слоёв. Там, где один и тот же объект живёт в SQLAlchemy, в ответе API и в тестах, начинаются сюрпризы с мутацией, сериализацией и лишними запросами.

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

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