Publication Flask ломают не роуты, а отсутствие границ между кодом и инфраструктурой

Flask ломают не роуты, а отсутствие границ между кодом и инфраструктурой В Flask слишком легко начать с «одного файла» и незаметно притащить в него всё: конфиг, бизнес-логику, SQL, шаблоны, интеграции. Через месяц такой app.py уже не поддерживается, а любой новый эндпоинт требует раскопок по всему проекту. Рабочая схема простая: — app factory вместо глобального app; — blueprints для разрезания домена по модулям; — отдельные слои для сервисов, репозиториев и адаптеров; — конфиг через окружение, а не через хардкод; — расширения и middleware подключать в одном месте, а не по всему коду. Ещё одна типовая ошибка — тащить в view всё подряд. View должен принимать запрос, валидировать вход, вызвать сервис и вернуть ответ. Если в нём есть SQL-запросы, HTTP-клиенты и ветвления на 80 строк, проект уже не Flask-лайт, а монолит без структуры. Для фоновых задач и внешних интеграций лучше сразу отделять их от request-response цикла: очереди, отдельные воркеры, явные таймауты и ретраи. Иначе любой медленный API начнёт тормозить весь веб-поток. Если Flask нужен в проде, держите его как тонкий HTTP-слой, а не как место, где живёт вся логика. Тогда приложение остаётся маленьким по коду, но большим по масштабу.