<b>FastAPI ломается не на роутинге, а на границе входных данных и зависимостей</b>

<b>FastAPI ломается не на роутинге, а на границе входных данных и зависимостей</b>

В проектах на FastAPI почти всегда всплывают одни и те же места:
— слишком тонкие Pydantic-схемы, где обязательные поля проверяются уже в бизнес-логике;
— зависимости, которые тянут БД, кэш и внешний API в один слой;
— асинхронные обработчики, внутри которых внезапно живёт блокирующий код.

Есть наблюдение которое стоит проверить: чем раньше запрос превращается в валидированную структуру, тем меньше ветвится код дальше. Для этого полезно держать отдельные схемы для входа, ответа и внутреннего контракта, а не переиспользовать один модельный класс везде. Так меньше магии при рефакторинге и проще ловить несовместимость между ручкой и сервисом.

Ещё одна частая ошибка — делать dependency injection “по привычке”, а не по границам ответственности. Если зависимость только достаёт пользователя, она не должна знать про скидки, очереди и бизнес-правила. Как только dependency начинает разрастаться, тесты становятся дорогими, а ручка — неочевидной.

И отдельно про async: если внутри endpoint’а есть тяжёлый sync-код, его лучше вынести в пул или в отдельный воркер. Иначе FastAPI выглядит асинхронным только на бумаге, а под нагрузкой упирается в блокировки.

Если держать схемы, зависимости и async-границы раздельно, FastAPI остаётся быстрым не только на бенчмарке, но и в сопровождении.