Почему я выпилил готовую админку и написал свой фронтенд? История, которая знакома каждому, кто работает на FastAPI + SQLAlchemy (async) + Redis. Мне нужна была админка для управления ключами доступа в боте автоматизации. Думал: «Поставлю готовую — сэкономлю время». Потратил уйму времени на попытки подружить её с асинхронным стеком и своим локальным exe клиентом. Итог: выпилил полностью. Что пошло не так: · ⚡ Асинхронность — готовые админки живут в синхронном мире. AsyncSession для них — красная тряпка. · 🧩 Зависимости — каждая библиотека тащила свою версию Pydantic и SQLAlchemy. Конфликты на ровном месте. · 🗄️ Redis — мои сессии и кеши жили в Redis, а админка пыталась натянуть свои middleware. Получился хаос. · 🐘 Alembic — админка хотела создавать свои таблицы, конфликтовала с моими моделями. 😱😱😱 ключи удалялись при новом запуске приложения это основная проблема, хоть и по логам терминала проблем не наблюдалось. Решение: сделать отдельный фронтенд. Взял React + Next.JS. Написал 4 страницы: список ключей, создание (с показом токена 1 раз), отзыв, удаление. Бекенд — свои эндпоинты в FastAPI. Что получил: ✅ Полный контроль — никаких "сюрпризов" от сторонних библиотек ✅ Безопасность — ключ показывается только при создании, в БД хранится хеш ✅ Легкий контейнер — образ стал меньше в 10 раз ✅ UX для менеджеров — удобно, красиво, быстро Затраты: 1 вечер на фронт + интеграцию. Против мучений с готовым решением, который хоть и дает достаточно быстрый старт (не в моем случае) но имеет максимально простой не продающий себя интерфейс.

Мораль: готовые админки — для пет-проектов и синхронных монолитов. В современном асинхронном мире с Redis и кастомной архитектурой, SQL — отдельный фронт это не роскошь, а необходимость. А вы пишете свои админки или используете готовые? 👇

#FastAPI #React #Redis #Python #Автоматизация #DevOps #Фронтенд #разработкалоготипа