Post Starlette ломают не роуты, а мелочи вокруг ASGI-контура

Starlette ломают не роуты, а мелочи вокруг ASGI-контура Starlette часто берут как «лёгкий фундамент» для API и сервисов. И это работает, пока не начинаются мелкие, но дорогие ошибки: лишние обёртки middleware, путаница с sync/async и фоновые задачи, которые живут дольше запроса. Есть наблюдение которое стоит проверить: — любой тяжёлый код в endpoint лучше уносить в отдельный слой, а не прятать в handler; — middleware держите коротким: аутентификация, логирование, заголовки, всё остальное — наружу; — если нужен streaming или SSE, тестируйте поведение клиента и отмену соединения отдельно. Ещё один частый промах — использовать Starlette как «мини-Django». Это не про шаблоны на всё подряд и не про бизнес-логику в роутере. Внятная схема такая: роут отвечает за транспорт, dependency или сервис — за данные, отдельный модуль — за интеграции и очереди. Тогда приложение проще покрывать тестами и переносить между проектами. Для production полезно сразу проверить: корректность исключений, таймауты на внешние вызовы, graceful shutdown, лимиты на тело запроса и поведение на отмене задачи. Именно эти места обычно всплывают не в демо, а под реальной нагрузкой. Если Starlette кажется «слишком простым», это плюс: простота быстро показывает, где у вас архитектура, а где набор привычек.