Концепт

Мы хотим создать два сайта.

Кастомный лендинг (верстаем по макету) для SEO и продвижения (с посадочными страницами для привлечения клиентов и т.п.). Он должен располагаться в корне домена, например vgen.com. Это набор абсолютно статичных HTML-страниц без бэкенда.

Административная панель для регистрации и управления заданиями. Её можно разместить на поддомене app.vgen.com. Для административной панели мы будем использовать SSR с проверкой session cookie для контроля доступа к целевым разделам.

User Stories

Как пользователь я хочу:

Регистрация/Верификация

Иметь возможность зарегистрироваться, используя email и пароль. Неверифицированный аккаунт не может войти в систему (при попытке авторизации будет показано сообщение о необходимости верификации). Для верификации я должен зайти в почту и перейти по ссылке активации. Ссылка работает в течение 24 часов. При попытке авторизации или сброса пароля для неактивированного email мне приходит ссылка на активацию аккаунта.

Регистрация используя googole auth

Иметь возможность зарегистироваться или залогинится используя google auth кнопку, вместо использования емейла.

Сброс пароля

Иметь возможность сбросить пароль в случае, если я его забыл. Ожидаю, что мне придёт ссылка на сброс пароля. Ссылка активна в течение 24 часов.

Авторизация

Иметь возможность войти в систему, используя логин и пароль, установленные при регистрации.

Просмотр баланса

Иметь возможность увидеть текущий баланс токенов.

Просмотр истории изменений баланса

Иметь возможность увидеть, когда и как изменялся баланс.

Пополнение баланса

Иметь возможность пополнить баланс на заданные суммы. Например:

• 10 000 токенов — 10 USD
• 30 000 токенов — 25 USD
• 70 000 токенов — 50 USD

Просмотр списка заданий

Иметь возможность посмотреть список всех созданных мною заданий в системе.

Создание нового задания

Иметь возможность создать новое задание, выбрав тип модели.

Редактирование созданного задания

Иметь возможность зайти в созданное задание для загрузки в него материалов (видео, аудио).

Запуск задания

Иметь возможность запустить ранее созданное и отредактированное задание.

Просмотр статуса выполнения задания

Иметь возможность посмотреть статус выполнения ранее созданных заданий.

Загрузка результата выполнения задания

Иметь возможность загрузить результат выполнения задания.

Перегенерация выполненного задания

Иметь возможность запустить перегенерацию задания в случае, если результат мне не понравился (без повторной загрузки данных).

Макеты приложения

balsamiq original

Landing

Лендинг должен содержать:

• Посадочную страницу с информацией о продукте
• Страницу Terms of Service
• Страницу Privacy Policy

Все страницы должны иметь call-to-action — переход на страницу регистрации в продукте.

Посадочная страница должна содержать примеры уже сгенерированных клипов (оптимально 5-10 в разных категориях).

Посадочная страница должна содержать информацию о ценах.

Посадочная страница должна иметь ссылку на бота поддержки в Telegram.

В лендинге должна быть возможность добавления отдельных страниц при необходимости (делать это при помощи кода, лендинг не должен ломаться от таких изменений).

Лендинг должен поддерживать многоязычность. Основной язык - английский. Формат страниц должен быть вида:

• /: главная страница на английском
• /uk: главная страница на украинском
• /terms: страница с правилами использования (только английский)
• /privacy: страница с политикой конфиденциальности (только английский)

SEO-оптимизация для лендинга ограничивается следующими настройками:

• meta-теги
  • title
  • description
• json-ld
  • schema.org organization
  • schema.org site
• HTML
  • h1/h2 tags

Я не вижу смысла интегриовать систему переводов в лендинг из пары страниц, поэтому предлагаю просто сделать страницы с разными языками руками.

Приложение (APP)

Приложение является MPA с поддержкой session-based авторизации. Приложение не требует SEO или SSR, поскольку отсутствует доступ для неавторизованных пользователей. Приложение должно поддерживать многоязычность. Мы хотим редактировать переводы через weblate.

В дизайне приложения мы используем стандартные компоненты — максимально простой, но функциональный дизайн. Мы не создаем custom-вёрстку и не делаем специальных элементов интерфейса.

Сохранение данных в DWH (BigQuery)

Помимо хранения балансов и данных о пользователях в D1, мы хотим сохранять в BigQuery некоторые данные для дальнейшего анализа.

Пользовательские сессии

При каждой авторизации пользователя я хочу сохранять:

• timestamp — время авторизации
• ip — IP-адрес
• geo — географические данные
• useragent — данные браузера/устройства
• action — тип действия: login/signup (вход или регистрация)
• userid — идентификатор пользователя
• email — email пользователя в системе

Изменения баланса токенов

Каждое изменение баланса или попытка изменения баланса должны быть сохранены в отдельной таблице:

• timestamp — время транзакции
• userid — идентификатор пользователя
• email — email пользователя
• action — тип действия: topup, used, manual
• diff — количество токенов, на которое произведено изменение
• old_balance — баланс до транзакции
• new_balance — баланс после транзакции

Важно: здесь мы не отражаем попытки оплаты или любые иные финансовые операции — это именно лог изменений количества токенов, привязанных к пользователю.

Лог запуска генераций

У нас нет доступа к логам API, но для отладки нам нужно хранить информацию о том, когда и какие задания мы запускали. Поэтому нам нужна таблица, где будет указано, когда и какой пользователь запускал какие задания и с какими ID. Наше API забывает (удаляет) истекшие задания, без такого лога у нас будут проблемы:

• timestamp — время запуска
• userid — идентификатор пользователя
• email — email пользователя
• taskid — идентификатор задания
• task_properties — свойства задания (to be defined)

Admin API

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

Все API имеют защиту при помощи фиксированного admin-token, который необходимо передавать в заголовке Authorization. Токен задается в переменных окружения приложения.

Изменение статуса пользователя

PUT /api/internal/user
{
  "userID": "njknjk",
  "status": "activated | new | blocked"
}

Метод необходим для ручной активации пользователя, который не может получить письмо активации, или блокировки пользователя, с которым мы больше не хотим работать.

Изменение баланса пользователя

PUT /api/internal/balance
{
  "userID": "ndskd",
  "diff": "100 | -100"
}

Метод должен возвращать информацию о старом балансе, изменении и новом итоговом балансе. При помощи метода можно как увеличивать, так и уменьшать количество токенов у пользователя.

Analytics

Для сбора веб аналитики на сайте должен быть установлен Google Tag Manager. При этом для авторизированных пользователей должен передаваться userId и email пользователя в dataLayer. Внутрь GTM должен быть положен GA, который бы трекал page-views и userID dimension. Дальнейшая настройка GA - out of scope.

Для анализа данных из BigQuery мы подключим MetaBase (его развёртывание находится вне области задач проекта, он у нас уже есть, и мы просто выдадим доступ заданному списку пользователей).

Управление стоимостью токена

В проекте будет создан конфиг, к примеру prices.ts, следующего формата:

prices = [
  {
  name: "small",
  price: 1000, // 10usd, denomination 100
  tokens: 10_000,
  discount: 0,
  },
  {
  name: "medium",
  price: 3000, // 30usd, denomination 100
  tokens: 30_000,
  discount: 5, // размер скидки в процентах
  },
   {
  name: "large",
  price: 5000, // 50usd, denomination 100
  tokens: 70_000,
  discount: 10, // показывается сверху панельки с пакетом, если отлична от 0
  }
]

Таким образом, при необходимости изменить ценообразование необходимо будет внести правки в конфиг. При этом уже приобретённые токены никуда не деваются и не переоцениваются. При необходимости можно делать разные бандлы, регулируя стоимость токена таким образом (к примеру крупным покупателям стоимость может выходить дешевле)

Платежная система

Как платежное решение мы подключим https://api.apay.pp.ua/docs/api. Под капотом будет onramp-решение для криптовалют. При необходимости можно будет подключить что-то ещё. В целом идея — отделить платежную систему от сервиса, поскольку они могут меняться (отключаться, восстанавливаться и т.п.).

Безопасность

Приложение публикуется на Cloudflare. При необходимости активации DDoS-защиты, rate-limiting и т.д. мы используем функционал, встроенный в Cloudflare поверх домена, на котором публикуем приложение. Каких-то дополнительных механизмов защиты мы не предусматриваем.

Время жизни сессии — 7 дней. Сброс сессии происходит при смене страны или смене User-Agent.

Файловое хранилище и валидация загрузок

Приложение выполняет только клиентскую валидацию файлов (проверка размера и расширения). Мы ожидаем, что нам предоставят список допустимых расширений, и, например, мы ограничим максимальный размер загружаемого файла.

Мы не сохраняем файлы на уровне приложения — сразу передаём их дальше в API продукта. Никакой обработки файлов не происходит.

Предполагаемые ограничения:

• Максимальный размер файла: 100 МБ
• Поддерживаемые форматы видео: MP4, MOV, AVI
• Поддерживаемые форматы аудио: MP3, WAV, M4A
• Максимум одновременных заданий на пользователя: 3

Email-уведомления

Фактически мы используем электронную почту только для верификации email-адреса. Для отправки писем предлагаем использовать Mailgun (необходимо будет предоставить нам аккаунт или API-ключи от него).

Типы уведомлений:

• Верификация email при регистрации
• Сброс пароля

User Engagement

Для работы сcustomer journey мы предлагаем инетгрировать customer.io. Его можно использовать для отправки рассылок пользователям. Для интеграции сustomer.io мы планируем использовать bigquery как источник данных для Customer. При этом на сайте нам необходимо будет установить их JS код интеграции.

Environments и развёртывание

Окружения

Мы поднимем два окружения — staging и production. Для удобства мы разносим их на разные домены:

• Staging: находится в доменной зоне pages.dev и в отдельном Cloudflare Workers проекте
• Production: привязывается к production-домену

При этом база D1, KV и environment-переменные у окружений полностью независимы.

Риски

Могут возникнуть проблемы с передачей файлов в API. Workers имеют много ограничений, связанных со временем исполнения, что может создать нам проблемы.

Могут возникнуть проблемы с API (мы попросили внести некоторые изменения в API, которые мы ещё ожидаем).

Файлы удаляются спустя некоторое время после генерации, это может привести к конфликтным ситуациям с пользователями (т.к. задания, как мы понимаем, будут пропадать из списка). Возможно, необходимо сделать где-то большой дисклеймер о том, что файлы нужно скачивать себе.

Ссылка на итоговый файл ведёт на домен API, что может привести к его раскрытию конечными пользователями и прямой атаке на него (рекомендуем реализовать сохранение сгенерированных файлов в Cloudflare R2).