Starlette ломают не роуты, а границы между ASGI, middleware и state

Starlette ломают не роуты, а границы между ASGI, middleware и state

Starlette часто берут как «лёгкий каркас» для API, но ошибки там почти всегда не в декораторах, а в архитектуре приложения. Если держать в голове 3 слоя — ASGI-событие, middleware-цепочку и обработчик запроса — половина багов становится предсказуемой.

— Middleware должен быть максимально тупым: логирование, заголовки, трейсинг. Если там бизнес-логика, потом сложно понять, где именно сломался ответ.
— State приложения и state запроса не путать: app.state — для общих зависимостей, request.state — для данных конкретного прохода.
— Если используешь фоновые задачи, не рассчитывай на «магический» доступ к контексту запроса: всё нужное передай явно.

Ещё одна типовая ловушка — отдавать слишком много ответственности endpoint'у. В Starlette удобно писать короткие async-обработчики, но как только в них появляются валидация, доступ к БД, форматирование ответа и ретраи, лучше вынести это в сервисный слой. Иначе приложение выглядит простым только в первый месяц.

Хорошее правило: Starlette оставляй тонким транспортом, а доменную логику — отдельно. Тогда его легко тестировать, проще масштабировать и почти невозможно случайно превратить в комок из middleware и глобального состояния.