Post FastAPI ломается не на роутинге, а на границах данных и зависимостей

FastAPI ломается не на роутинге, а на границах данных и зависимостей В проектах на FastAPI чаще всего проблемы прячутся не в эндпоинтах, а в том, что вокруг них: схемы, DI, фоновые задачи, подключение БД. Если оставить это «на потом», API ещё отвечает, но уже живёт на допусках и костылях. Три места, которые надо жёстко дисциплинировать: — входные модели: не пускайте в обработчик «сырой» dict, только pydantic-схемы; — зависимости: всё, что открывает соединение или читает конфиг, должно быть в одном слое; — ошибки: единый формат ответа важнее, чем десяток `raise HTTPException` в каждом файле. Ещё одна типовая ошибка — смешивать бизнес-логику с endpoint-функцией. Когда в `router` лежат и валидация, и SQL, и отправка письма, тесты становятся дорогими, а рефакторинг опасным. Лучше держать обработчик тонким: принял данные, вызвал сервис, вернул ответ. Если нужен API, который не развалится после пары расширений, проектируйте границы заранее: схема на входе, сервис в середине, адаптеры снаружи. Тогда FastAPI остаётся быстрым, а не просто удобным для старта.