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

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

Starlette часто берут как «лёгкий каркас», но проблемы обычно не в нём, а в том, как собирают приложение:
— смешивают бизнес-логику с обработчиками;
— вешают тяжёлые sync-вызовы прямо в async endpoint;
— забывают про единый слой ошибок и ответов.

Если проект растёт, сразу отделяйте routing, services и dependencies. Роут должен принимать request, вызывать сервис и возвращать response. Всё остальное — не его задача. Так проще тестировать, менять transport и не тащить веб-слой в доменную логику.

Для фоновых задач и внешних запросов держите отдельные адаптеры. Внутри Starlette удобно делать тонкие endpoint’ы, а тяжёлое выносить в threadpool, очередь или отдельный worker. Иначе любой «быстрый» хендлер начинает блокировать соседей, а диагностика превращается в угадайку.

Ещё одна частая ошибка — игнорировать middleware и lifespan. Именно там обычно живут логирование, метрики, соединения с БД и кэшом. Если это раскидано по ручкам, сопровождение быстро дорожает.

Хорошая проверка простая: если endpoint нельзя переписать без знания деталей БД, очереди и HTTP-клиента, архитектура уже течёт.