Post Starlette — это не «мини-FastAPI», а каркас, который удобно ломать и собирать под себя

Starlette — это не «мини-FastAPI», а каркас, который удобно ломать и собирать под себя Если нужен тонкий HTTP-слой для микросервиса, вебхуков или внутреннего API, Starlette часто выигрывает за счёт простоты: маршруты, middleware, фоновые задачи, WebSocket — без лишней магии. Он хорош там, где важнее контролировать поведение, чем тащить большой фреймворк ради пары эндпоинтов. Что обычно делают неправильно: • Пишут sync-хендлеры и потом удивляются блокировкам в проде • Вешают тяжёлую логику прямо в endpoint вместо сервиса или очереди • Игнорируют lifespan-события и теряют инициализацию клиентов, пулов, кешей • Смешивают ручную работу с request/response и начинают плодить дублирование Если проект растёт, Starlette удобно использовать как базу для тонкой архитектуры: отдельно слой транспорта, отдельно бизнес-логика, отдельно интеграции. Это особенно заметно в async-проектах, где один плохо написанный handler может тормозить весь ворклоад. Ещё плюс: Starlette легко тестировать и легче читать в ревью, когда в коде нет лишнего «магического» слоя. Но это работает только если сразу договориться о границах: где валидируются данные, где ловятся ошибки, где живут зависимости. Хорошее правило простое: если вам нужен контроль над HTTP и минимум абстракций, Starlette — не компромисс, а осознанный выбор.