Post FastAPI ломают не роуты, а границы между схемами, логикой и БД

FastAPI ломают не роуты, а границы между схемами, логикой и БД За неделю в репах: почти все проблемы в FastAPI начинаются не в async, а в архитектуре. Когда endpoint тянет ORM, валидирует вход, собирает бизнес-правило и еще форматирует ответ — проект быстро превращается в набор связанных функций. Разделяйте слои сразу: — router только принимает запрос и отдает ответ — service держит бизнес-логику — repository знает про БД — schemas описывают контракт, а не внутренности модели Есть наблюдение которое стоит проверить: чем меньше кода в обработчике, тем проще тестировать таймауты, ошибки и валидацию. Особенно если зависимости передаются через Depends, а не импортируются внутри функции. Тогда заменять реализацию в тестах и фоновых задачах становится заметно проще. Еще одно правило: не смешивайте Pydantic-схемы и ORM-объекты в одном слое без необходимости. Схема для входа, схема для ответа, модель для хранения — это не бюрократия, а способ не ловить случайные изменения полей по всему проекту. Если FastAPI начинает казаться “слишком простым”, проверьте не фреймворк, а границы модулей: там обычно и лежит причина будущего техдолга.