Post Starlette ломают не роуты, а то, как с ней обращаются в middleware и стримах

Starlette ломают не роуты, а то, как с ней обращаются в middleware и стримах Starlette часто берут как «лёгкий ASGI-слой», а потом удивляются: приложение работает, но сложнее отлаживать ошибки, фоновые задачи и пропущенные заголовки. Есть наблюдение которое стоит проверить: большинство проблем появляется не в endpoint’ах, а на границах запроса. • Middleware держите короткими. Если в одном слое и auth, и логирование, и нормализация ответа — дебаг превращается в квест. • Для тяжёлых операций не блокируйте event loop: выносите CPU-bound в отдельный процесс, а I/O — в асинхронные вызовы. • Стриминг ответа тестируйте отдельно. Любая ошибка после первого чанка уже не «обычный 500», а частично отправленный ответ. Ещё два места, где Starlette часто недооценивают: lifespan и state. Инициализация соединений, пулов и кэшей должна жить в startup/shutdown, а не в первом запросе. Если нужен общий объект между слоями, не прячьте его в глобалы — прокидывайте через request.state или контейнер зависимостей. Если проект маленький, Starlette даёт чистую базу без лишней магии. Если проект растёт — заранее фиксируйте границы middleware, lifecycle и async-IO. Потом это экономит часы, а не минуты.