Starlette: почему быстрый ASGI-фреймворк ломается не на коде, а на обвязке

Starlette часто берут ради скорости и простоты, но в проде проблемы обычно не в роутинге. Ломается всё вокруг: middleware, фоновые задачи, обработка ошибок, проксирование и то, как вы собираете ответы.

Есть наблюдение которое стоит проверить: если проект на Starlette «вдруг стал сложным», значит вы уже нарастили поверх него мини-Django без дисциплины. Чтобы не утонуть:
• держите бизнес-логику вне эндпоинтов
• не прячьте ошибки в middleware
• явно разделяйте sync и async границы
• не передавайте сырые request/response глубоко в сервисы

Отдельно следите за жизненным циклом приложения. Инициализация клиентов, пулов и кэшей должна быть в startup/lifespan, а не в первом запросе. Иначе вы получаете странные задержки, гонки и «магические» падения под нагрузкой. Для фоновки лучше использовать очередь или отдельный воркер, а не надеяться, что request уже ушёл и всё само доедет.

Если нужен тонкий HTTP-сервис, Starlette хорош как каркас. Но как только появляются авторизация, схемы, валидация и админка — заранее решите, где заканчивается фреймворк и начинается ваш слой приложения. Иначе экономия на старте превращается в дорогую переделку позже.