Profile photo
Smirnoff

10 min read

PromtGen: backend roadmap

Текущая версия PromtGen уже решает практическую задачу: помогает собрать image prompts, video prompts, JSON payload для VEO-сценариев и AI-описания через Gemini без ручного хаоса в заметках и черновиках. Для guided workspace этого достаточно: пользователь открывает форму, проходит по полям, получает аккуратный prompt и уносит его в нужный AI-инструмент.

Но у такого подхода есть потолок. Архитектурно PromtGen пока остаётся клиентским React/Vite-приложением: static SPA без backend API, авторизации, базы данных, persistent sessions, очередей и безопасного серверного слоя для AI-вызовов. Это нормально для быстрого конструктора, но становится ограничением, если PromtGen должен помнить проекты, запускать генерацию внутри себя и выдерживать production-сценарии.

Этот roadmap пока не реализован. Его задача — честно показать путь от режима «собрали prompt и скопировали наружу» к режиму «собрали задачу, сгенерировали результат внутри проекта, сохранили историю и вернулись к ней позже». Здесь важно не приписывать текущему продукту backend-возможности, а зафиксировать, какой серверный контур понадобится, если PromtGen будет расти из удобного prompt builder в устойчивый workspace для AI-контента.

Текущее состояние

Сейчас PromtGen работает просто и прозрачно:

  1. пользователь открывает SPA;
  2. выбирает image или video режим;
  3. заполняет форму;
  4. prompt собирается в браузере;
  5. AI-assisted функции вызываются с клиента через @google/genai;
  6. результат копируется вручную;
  7. история и draft не сохраняются на сервере; часть UI state доступна через URL state, но это не persistent session.

В этом есть своя сила. Текущая версия не требует сложной инфраструктуры и позволяет быстро проверять самую важную часть продукта — насколько удобно человеку собрать качественный prompt под конкретный визуальный или видео-сценарий.

Сильные стороны текущей версии:

  • быстрый локальный запуск;
  • нет серверной инфраструктуры;
  • простая разработка UI;
  • уже есть понятные доменные модели FormState и VeoFormState;
  • есть category presets, VEO options и behavior patterns;
  • есть review/validation логика для видео.

Ограничения становятся заметны там, где пользователь хочет не просто собрать текст, а продолжить работу с результатом как с проектом:

  • API-ключ Gemini живёт на клиенте через Vite-переменную;
  • нет user/session model;
  • нельзя хранить проекты и версии промтов;
  • нет очередей для тяжёлой генерации;
  • нельзя безопасно подключать платные image/video/audio модели;
  • нет биллинга, rate limits и аудита запросов;
  • невозможно полноценно продолжать работу с генерациями между устройствами;
  • формального test-suite нет: package scripts ограничены dev/build/preview.

Цель backend-этапа

Backend нужен не ради «ещё одного слоя» в архитектуре. Он нужен, чтобы PromtGen перестал быть одноразовой формой и начал вести себя как рабочее пространство: помнить контекст, безопасно вызывать AI-провайдеров, показывать статус долгих задач и хранить результат там же, где создавался prompt.

Конкретно backend должен открыть такие возможности:

  • безопасно хранить ключи AI-провайдеров;
  • выполнять генерацию изображений, видео и текстов на сервере;
  • сохранять drafts, prompt sessions и результаты;
  • управлять пользователями, лимитами и квотами;
  • подключать очереди для долгих задач;
  • возвращать статус генерации в интерфейс;
  • хранить assets: reference images, generated images, video previews, JSON payloads;
  • сделать PromtGen не только prompt builder, а production workspace.

Если frontend отвечает за удобный guided workflow, то backend должен отвечать за надёжность: где лежат данные, кто имеет к ним доступ, какие запросы ушли к провайдерам, сколько они стоят и как пользователь возвращается к работе позже.

Предлагаемая архитектура

Минимальная целевая схема:

Frontend (React/Vite)
  -> Backend API
     -> Auth / users
     -> Prompt sessions
     -> AI provider adapters
     -> Generation jobs
     -> Asset storage
     -> Database
     -> Queue / workers

Эта схема не пытается сразу описать «идеальную платформу». Она показывает базовый контур, без которого сложно безопасно запускать генерации, сохранять проекты и поддерживать историю действий.

Backend API

Серверный API должен принять на себя операции, которые нельзя оставлять на клиенте:

  • вызовы Gemini / image / video / audio providers;
  • хранение provider keys;
  • создание generation jobs;
  • сохранение результатов;
  • валидация и нормализация prompt payload;
  • rate limiting;
  • user access control.

На первом этапе backend может быть простым Node.js API. Для текущего стека логично выбирать TypeScript, чтобы переиспользовать доменные типы и prompt builders. Практический смысл здесь в том, чтобы не разводить две разные модели продукта: UI собирает payload, сервер проверяет и исполняет его по тем же правилам.

Database

База нужна не «для галочки», а для памяти проекта. Без неё PromtGen каждый раз начинается заново; с ней появляются sessions, история попыток, drafts и связь между prompt, исходными материалами и результатами.

Рабочие сущности:

  • пользователи;
  • prompt sessions;
  • image card drafts;
  • video promo drafts;
  • generation jobs;
  • generated assets;
  • provider responses;
  • usage/cost events;
  • project folders или collections.

Для старта достаточно PostgreSQL. Она хорошо подходит для структурированных данных, JSON payloads и истории операций.

Queue / workers

Генерация видео и изображений может занимать время. Если держать всё в прямом request-response, интерфейс быстро станет хрупким: пользователь ждёт, запрос может оборваться, а статус задачи негде нормально хранить. Поэтому нужна очередь:

  1. frontend отправляет generation request;
  2. backend создаёт job;
  3. worker вызывает AI provider;
  4. статус обновляется в базе;
  5. frontend получает progress/status;
  6. результат сохраняется и показывается пользователю.

Для MVP можно начать с простой таблицы jobs и polling. Следующий шаг — Redis/BullMQ или другой queue-layer. Главное — с самого начала мыслить генерацию как задачу с жизненным циклом, а не как один синхронный HTTP-вызов.

Asset storage

PromtGen должен хранить не только текст, но и файлы, потому что реальные AI-сценарии быстро становятся мультимодальными: товарная картинка, reference image, превью, JSON export, будущий audio draft.

Нужно хранить:

  • reference images;
  • загруженные product images;
  • generated images;
  • video previews;
  • thumbnails;
  • JSON payload exports;
  • будущие audio drafts.

Локально это может быть файловое хранилище, в production — S3-compatible storage.

Что вынести из frontend в backend

AI-вызовы

Сейчас DescriptionPanel.tsx и VeoPanel.tsx вызывают Gemini с клиента. Для прототипа это ускоряет разработку и уменьшает количество движущихся частей. Для production это уже риск:

  • ключ виден клиентскому приложению;
  • невозможно централизованно контролировать стоимость;
  • сложно вести историю запросов;
  • нет нормального rate limiting;
  • нельзя скрыть provider-specific детали.

Нужны backend endpoints:

POST /api/ai/description
POST /api/ai/analyze-image
POST /api/ai/video-shot-description
POST /api/ai/visual-style

Frontend должен отправлять нормализованный контекст, а backend — выбирать provider, модель и системные инструкции. Так пользователь по-прежнему работает в понятном интерфейсе, но чувствительная и дорогая часть процесса уходит в контролируемый серверный слой.

Prompt builders

Сейчас prompt-building logic частично живёт в App.tsx и VeoPanel.tsx. Пока продукт небольшой, это терпимо. Но как только одна и та же логика нужна UI, API, тестам и сохранённым sessions, её лучше вынести в pure-модули:

src/prompt-builders/imageCardPrompt.ts
src/prompt-builders/videoPrompt.ts
src/prompt-builders/audioPrompt.ts

Преимущества:

  • можно тестировать сборку prompt отдельно от UI;
  • backend и frontend смогут использовать одну логику;
  • проще версионировать prompt templates;
  • можно хранить template version в session/job.

Такой шаг не меняет пользовательский сценарий, но делает архитектуру взрослее: prompt перестаёт быть побочным эффектом компонента и становится отдельной доменной логикой.

Validation

Валидация видео уже есть в VeoPanel.tsx, но backend должен повторять критичные проверки. Клиентская проверка помогает UX: человек раньше видит ошибку и быстрее исправляет форму. Серверная проверка защищает данные, provider calls и будущие лимиты.

Backend должен валидировать:

  • обязательные поля;
  • длительности;
  • ограничения provider API;
  • формат reference assets;
  • максимальные размеры prompt;
  • поддерживаемые aspect ratio и resolution;
  • права пользователя на session/assets.

Роадмап по этапам

Этап 1. Подготовка доменной модели

Цель: отделить бизнес-логику от UI и подготовить минимальную базу для backend без изменения пользовательского сценария.

Задачи:

  • вынести image prompt builder из App.tsx;
  • вынести video prompt builder из VeoPanel.tsx;
  • вынести validation для VeoFormState;
  • покрыть prompt builders и validation unit-тестами, потому что формального test-suite сейчас нет;
  • описать версии prompt templates;
  • унифицировать типы для будущего API;
  • подготовить server-side Gemini proxy как первый реальный backend endpoint, чтобы убрать ключ из client-side кода.

Результат: frontend работает как раньше, но логика готова к переиспользованию на сервере. Это безопасный первый шаг: пользователь ничего не теряет, а проект получает основу для следующих этапов.

Этап 2. Backend MVP

Цель: добавить серверный слой без полной перестройки интерфейса.

Задачи:

  • поднять Node.js/TypeScript backend;
  • добавить health endpoint;
  • добавить endpoints для Gemini-assisted функций;
  • перенести Gemini key на сервер;
  • добавить базовый logging;
  • добавить server-side validation;
  • настроить env-переменные backend.

Результат: AI-assisted действия больше не требуют exposing ключа в браузере. Для пользователя это выглядит почти так же, но внутри появляется контролируемая точка входа для AI-функций.

Этап 3. Drafts и prompt sessions

Цель: дать пользователю возможность сохранять работу.

Сущности:

PromptSession
  id
  userId
  mode: image | video | audio_video
  title
  formState
  promptOutput
  templateVersion
  createdAt
  updatedAt

Задачи:

  • добавить PostgreSQL;
  • сохранять image drafts;
  • сохранять video drafts;
  • открывать session по id;
  • добавить autosave;
  • добавить список последних проектов;
  • хранить query-state не как единственный способ восстановления, а как UI convenience.

Результат: PromtGen становится workspace, а не одноразовой формой. Человек может вернуться к идее, доработать prompt, сравнить версии и не начинать каждый сценарий с чистого листа.

Этап 4. Генерация изображений внутри проекта

Цель: перестать ограничиваться копированием prompt наружу.

Задачи:

  • добавить endpoint POST /api/generations/image;
  • подключить provider adapter для image generation;
  • поддержать reference image upload;
  • создать generation job;
  • показывать статус в UI;
  • сохранять результат в assets;
  • дать возможность повторить генерацию с изменённым prompt;
  • хранить provider metadata.

Результат: пользователь собирает карточку и получает generated image прямо внутри PromtGen. Prompt, исходные материалы, попытки и итоговый asset остаются в одном контексте.

Этап 5. Генерация видео внутри проекта

Цель: связать VeoFormState, storyboard и provider API.

Задачи:

  • добавить endpoint POST /api/generations/video;
  • передавать full prompt или scene prompt;
  • сохранять JSON payload;
  • подключить long-running jobs;
  • добавить polling или realtime status;
  • хранить preview video / result URL;
  • отображать историю попыток по одной session;
  • добавить provider-specific ограничения по длительности, aspect ratio и resolution.

Результат: Video Promo становится не только prompt-конструктором, но и точкой запуска generation pipeline. Это уже другой уровень ответственности: видео дольше, дороже и сильнее нуждается в очередях, статусах и сохранённой истории.

Этап 6. Audio layer

Цель: добавить звук как часть video workflow.

Задачи:

  • добавить audio direction fields в video session;
  • генерировать voiceover script;
  • генерировать SFX prompts по кадрам;
  • генерировать music mood prompt;
  • поддержать отдельный audio prompt export;
  • позже подключить TTS/music/SFX provider через backend jobs.

Результат: PromtGen сможет готовить не только визуальный prompt, но и звуковой brief для ролика. Это делает video workflow ближе к реальному production-процессу, где картинка и звук проектируются вместе.

Этап 7. Пользователи, лимиты и production-контроль

Цель: подготовить продукт к реальному использованию.

Задачи:

  • авторизация;
  • user projects/collections;
  • лимиты генераций;
  • usage accounting;
  • cost tracking;
  • audit log;
  • rate limits;
  • роли admin/user;
  • экспорт результатов.

Результат: можно контролировать стоимость и доступ, а не раздавать генерацию всем без ограничений. Это слой, который превращает экспериментальный инструмент в сервис, способный пережить реальные сценарии использования.

Приоритеты MVP

Если идти прагматично, первые реальные шаги должны быть уже, чем полноценный product backend. Важно сначала убрать самые опасные и самые мешающие ограничения, а не строить большую платформу заранее:

  1. extraction of prompt builders из крупных UI-компонентов;
  2. unit-тесты на prompt builders и validation;
  3. server-side Gemini proxy для текущих AI-assisted функций;
  4. prompt sessions с сохранением drafts;
  5. image generation job;
  6. asset storage для результатов;
  7. минимальный экран истории генераций.

Видео generation можно подключать после того, как будет готова очередь и понятная модель jobs, потому что видео дороже и дольше по времени.

Что не стоит делать сразу

Этот список так же важен, как и roadmap. Он защищает проект от преждевременной сложности: можно потратить много сил на переписывание интерфейса или подключение провайдеров, но не решить главную проблему — надёжное сохранение и исполнение AI-задач.

  • Не переносить весь UI на новый фреймворк.
  • Не переписывать VeoPanel.tsx целиком до выделения prompt builders.
  • Не добавлять много providers без adapter interface.
  • Не запускать video generation без очередей и хранения статусов.
  • Не смешивать billing, auth и generation в одном неразделённом сервисе.
  • Не менять главное изображение карточки проекта: текущий preview_image должен остаться /images/prmt.webp.

Целевая пользовательская история

Будущий flow должен выглядеть так:

  1. пользователь создаёт проект «Новый товар»;
  2. загружает reference image;
  3. выбирает категорию и visual direction;
  4. собирает image card prompt;
  5. запускает генерацию изображения внутри PromtGen;
  6. сохраняет удачный результат;
  7. переходит в Video Promo;
  8. на основе того же товара собирает storyboard;
  9. генерирует video prompt и запускает video job;
  10. добавляет audio direction;
  11. получает историю всех попыток, prompt versions, assets и итоговые файлы в одном project workspace.

Это переводит PromtGen из «генератора текста для копирования» в систему управления AI-контентом для товара. Главное изменение не в том, что появляется backend как технология, а в том, что у пользователя появляется непрерывная рабочая линия: от идеи и reference image до prompt versions, generation jobs и сохранённых assets.

Визуал roadmap

Для roadmap используется отдельная обложка /images/promptgen-backend-roadmap-cover.webp: неоновая карта архитектуры с frontend, backend API, базой данных, очередями и generation nodes. Главное изображение проекта /images/prmt.webp сохранено для основной карточки PromtGen.

Связанные материалы

Graph View

Backlinks