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

FastAPI ломается не на роутинге, а на границе входных данных и зависимостей В проектах на FastAPI почти всегда всплывают одни и те же места: — слишком тонкие Pydantic-схемы, где обязательные поля проверяются уже в бизнес-логике; — зависимости, которые тянут БД, кэш и внешний API в один слой; — асинхронные обработчики, внутри которых внезапно живёт блокирующий код. Есть наблюдение которое стоит проверить: чем раньше запрос превращается в валидированную структуру, тем меньше ветвится код дальше. Для этого полезно держать отдельные схемы для входа, ответа и внутреннего контракта, а не переиспользовать один модельный класс везде. Так меньше магии при рефакторинге и проще ловить несовместимость между ручкой и сервисом. Ещё одна частая ошибка — делать dependency injection “по привычке”, а не по границам ответственности. Если зависимость только достаёт пользователя, она не должна знать про скидки, очереди и бизнес-правила. Как только dependency начинает разрастаться, тесты становятся дорогими, а ручка — неочевидной. И отдельно про async: если внутри endpoint’а есть тяжёлый sync-код, его лучше вынести в пул или в отдельный воркер. Иначе FastAPI выглядит асинхронным только на бумаге, а под нагрузкой упирается в блокировки. Если держать схемы, зависимости и async-границы раздельно, FastAPI остаётся быстрым не только на бенчмарке, но и в сопровождении.