Post Starlette ломается не из-за ASGI, а из-за пары привычек в проекте

Starlette ломается не из-за ASGI, а из-за пары привычек в проекте Starlette часто берут как «лёгкий каркас», но проблемы обычно не в нём, а в том, как собирают приложение: — смешивают бизнес-логику с обработчиками; — вешают тяжёлые sync-вызовы прямо в async endpoint; — забывают про единый слой ошибок и ответов. Если проект растёт, сразу отделяйте routing, services и dependencies. Роут должен принимать request, вызывать сервис и возвращать response. Всё остальное — не его задача. Так проще тестировать, менять transport и не тащить веб-слой в доменную логику. Для фоновых задач и внешних запросов держите отдельные адаптеры. Внутри Starlette удобно делать тонкие endpoint’ы, а тяжёлое выносить в threadpool, очередь или отдельный worker. Иначе любой «быстрый» хендлер начинает блокировать соседей, а диагностика превращается в угадайку. Ещё одна частая ошибка — игнорировать middleware и lifespan. Именно там обычно живут логирование, метрики, соединения с БД и кэшом. Если это раскидано по ручкам, сопровождение быстро дорожает. Хорошая проверка простая: если endpoint нельзя переписать без знания деталей БД, очереди и HTTP-клиента, архитектура уже течёт.