Как собрать интерактивную платформу: профили, активности, баллы и AI-интеграция

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

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

Из чего состоял проект

Платформа объединяла несколько связанных контуров, поэтому важно было сразу проектировать не набор разрозненных страниц, а единый жизненный цикл пользователя и контента.

• Профили и доступ. Основной аккаунт, несколько профилей участников, переключение контекста и права на действия в зависимости от выбранного профиля.
• Тематические зоны. Игры, квизы, тесты, задания на сопоставление, творческие и совместные активности. У каждой активности — собственные правила прохождения, результат и начисление баллов.
• Прогресс и мотивация. Календарь открытия контента, история попыток, накопленные баллы и рейтинг. Баллы фиксируются транзакциями, поэтому историю можно объяснить и проверить, а не только показать текущее число.
• Материалы и события. Отдельные родительские материалы и онлайн-сессии с собственным расписанием, регистрацией и статусами.
• Административный контур. Управление контентом, пользователями, расписанием, поддержкой и выгрузками — без ручного редактирования базы данных.

Как разделили продуктовую и техническую ответственность

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

Такое разделение защищает бизнес-правила от клиентских манипуляций. Интерфейс может мгновенно показать следующий шаг, но окончательное решение о доступе, результате и начислении принимает сервер. Это особенно важно, когда контент открывается по календарю, попытку нельзя повторить или правила подсчета меняются в течение сезона.

Общий пользовательский сценарий

1. Вход и выбор профиля. Пользователь авторизуется в основном аккаунте, после чего выбирает профиль участника. Сервер возвращает только разрешенный контекст: возрастную группу, доступные зоны и текущий прогресс; переключение профиля не требует повторной регистрации.
2. Подбор доступных активностей. Платформа проверяет календарь открытия, сезонные правила, возрастные ограничения и историю попыток. Поэтому закрытая активность не появляется раньше времени, а уже завершенное задание не запускается повторно случайным кликом.
3. Прохождение механики. React ведет интерактивное состояние игры, квиза, теста или творческого задания: показывает шаги, таймеры, подсказки и промежуточную обратную связь. При этом ключевые ответы и правила проверки не считаются достоверными, пока их не подтвердит Laravel.
4. Фиксация результата. После завершения клиент отправляет на API идентификатор активности, профиль и итоговые данные попытки. Сервер повторно проверяет доступность и идемпотентность операции, сохраняет результат, создает транзакцию баллов и обновляет прогресс без двойного начисления.
5. Сопровождение и аналитика. Администратор видит статусы контента, пользователей, попыток и событий в отдельном контуре. Это позволяет быстро разобрать спорную ситуацию, открыть следующий материал по расписанию и подготовить выгрузку без доступа к внутренним таблицам.

Как выглядят разные активности

Отдельный технический эпизод: AI-генерация внутри продукта

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

1. Laravel проверяет входные данные. Backend подтверждает право на действие, допустимость выбранной основы и формат файла. Prompt и остальные критичные параметры остаются на сервере.
2. Изображение нормализуется. Файл приводится к предсказуемому формату и размеру до передачи во внешний сервис.
3. Создается запись генерации. API быстро возвращает идентификатор операции, а не удерживает браузер в ожидании модели.
4. Очередь и polling. Worker выполняет вызов, а интерфейс опрашивает только безопасный статус: ожидание, обработка, успех или ошибка.
5. Результат возвращается в платформу. Итоговый файл сохраняется через основной файловый контур и привязывается к нужному профилю и активности.

Зачем понадобился узкий защищенный proxy

Основное приложение отвечает за пользователей, правила, очередь, хранение и прогресс. Для связи с OpenAI Image Edits мы вынесли внешний вызов в отдельный no-store proxy. Он принимает только известный подписанный server-to-server запрос с двумя изображениями и серверными настройками, вызывает провайдера и возвращает стандартизированный результат.

• ключ и prompt не попадают в браузер;
• между сервисами принимаются только подписанные запросы с защитой от повторной отправки;
• оба изображения валидируются до обращения к провайдеру;
• исходный и итоговый файлы не остаются в постоянном хранилище proxy;
• Laravel получает безопасный JSON-контракт, а не сырое тело внешнего ответа.

Так AI-функция остается частью общей платформы: пользователь видит понятный результат и прогресс, а команда — наблюдаемый процесс с четкими границами ответственности и контролируемыми расходами.

Что делает такую платформу устойчивой

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

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

Итог для бизнеса

Вместо набора временных механик команда получает управляемую платформу: профили и права, контентные зоны, прогресс и рейтинг, события и административные инструменты. Отдельная AI-активность усиливает пользовательский опыт, но не ломает общую модель данных и процессов.

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

О том, почему ИИ ускоряет разработку только при инженерном контроле, рассказываем отдельно в статье «Когда разработка с ИИ действительно ускоряет проект».