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

Starlette: почему быстрый ASGI-фреймворк ломается не на коде, а на обвязке Starlette часто берут ради скорости и простоты, но в проде проблемы обычно не в роутинге. Ломается всё вокруг: middleware, фоновые задачи, обработка ошибок, проксирование и то, как вы собираете ответы. Есть наблюдение которое стоит проверить: если проект на Starlette «вдруг стал сложным», значит вы уже нарастили поверх него мини-Django без дисциплины. Чтобы не утонуть: • держите бизнес-логику вне эндпоинтов • не прячьте ошибки в middleware • явно разделяйте sync и async границы • не передавайте сырые request/response глубоко в сервисы Отдельно следите за жизненным циклом приложения. Инициализация клиентов, пулов и кэшей должна быть в startup/lifespan, а не в первом запросе. Иначе вы получаете странные задержки, гонки и «магические» падения под нагрузкой. Для фоновки лучше использовать очередь или отдельный воркер, а не надеяться, что request уже ушёл и всё само доедет. Если нужен тонкий HTTP-сервис, Starlette хорош как каркас. Но как только появляются авторизация, схемы, валидация и админка — заранее решите, где заканчивается фреймворк и начинается ваш слой приложения. Иначе экономия на старте превращается в дорогую переделку позже.