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