Пост Starlette ломают не маршруты, а обработчики запросов и фоновые задачи

Starlette ломают не маршруты, а обработчики запросов и фоновые задачи Starlette часто берут как «лёгкий ASGI-слой», а потом удивляются, почему приложение ведёт себя нестабильно. Главные причины обычно не в роутинге, а в том, как собраны middleware, зависимости и lifecycle. Проверь базовый набор: — не держи тяжёлую инициализацию в обработчике запроса; — не запускай блокирующий I/O напрямую внутри async-кода; — не полагайся на фоновые задачи для критичной бизнес-логики; — не смешивай state на уровне модуля с данными конкретного запроса. Ещё одна типовая ошибка — игнорировать границы между ASGI и синхронным кодом. Если внутри эндпоинта вызывается ORM, парсер или внешняя библиотека без обёртки, event loop начинает тормозить. Внешне это выглядит как «медленный Starlette», хотя проблема сидит в одной функции. Хорошая схема простая: всё, что может ждать, уводишь в отдельный worker; всё, что должно отвечать быстро, оставляешь в request path; для shared-данных используешь явные объекты, а не глобальные переменные. Если Starlette начинает «сыпаться», сначала смотри на блокировки, lifecycle и фоновые задачи — в этих трёх местах обычно спрятан реальный баг.