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

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

Starlette часто берут как «лёгкий ASGI-слой», а потом удивляются, почему приложение ведёт себя нестабильно. Главные причины обычно не в роутинге, а в том, как собраны middleware, зависимости и lifecycle.

Проверь базовый набор:
— не держи тяжёлую инициализацию в обработчике запроса;
— не запускай блокирующий I/O напрямую внутри async-кода;
— не полагайся на фоновые задачи для критичной бизнес-логики;
— не смешивай state на уровне модуля с данными конкретного запроса.

Ещё одна типовая ошибка — игнорировать границы между ASGI и синхронным кодом. Если внутри эндпоинта вызывается ORM, парсер или внешняя библиотека без обёртки, event loop начинает тормозить. Внешне это выглядит как «медленный Starlette», хотя проблема сидит в одной функции.

Хорошая схема простая: всё, что может ждать, уводишь в отдельный worker; всё, что должно отвечать быстро, оставляешь в request path; для shared-данных используешь явные объекты, а не глобальные переменные.

Если Starlette начинает «сыпаться», сначала смотри на блокировки, lifecycle и фоновые задачи — в этих трёх местах обычно спрятан реальный баг.