Post Flask в проде ломается не из-за фреймворка, а из-за вокруг него

Flask в проде ломается не из-за фреймворка, а из-за вокруг него Flask часто выбирают за простоту, и это же потом оборачивается хаосом: приложение растёт, а границы ответственности никто не зафиксировал. Сам фреймворк маленький — поэтому архитектуру вы собираете сами. Полезно сразу разделить: — конфиг: отдельные классы под dev/stage/prod, без ручных правок в коде; — app factory: чтобы тесты и фоновые задачи создавали приложение одинаково; — extensions: инициализация через объект, а не через глобальные импорты; — blueprints: когда модули уже не влезают в один файл; — ошибки и логирование: единый формат, иначе отладка превращается в археологию. Есть наблюдение которое стоит проверить: большинство проблем с Flask появляется не на уровне HTTP, а на уровне состояния. Глобальные переменные, кеши без границ, соединения, созданные «на всякий случай», — всё это работает до первого параллельного запроса или воркера. Если проекту нужны async-эндпоинты, сложная схема валидации и много интеграций, Flask можно оставить, но обвязку придётся строить дисциплинированно. Если нужна быстая API-платформа с меньшим количеством самосбора, часто проще смотреть в сторону FastAPI или Starlette. Правило простое: в Flask экономят не на коде, а на решениях, которые нужно принять заранее.