Релок

Когда клиент пришёл к нам, у него уже было несколько важных наработок:

• Рабочие боты — то есть частично готовый бэкенд. Логика продаж уже существовала, её нужно было перенести на сайт.

• Дизайн-макеты — клиент предоставил качественные макеты всех страниц. Это сильно упростило фронтенд-часть.

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

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

В чём особенность нетривиальной логики

Регион, в котором пользователь покупает игру, можно менять. Страницы реагируют на переключение региона по-разному:

• Каталог просто перезапрашивает список позиций, актуальных для выбранной локации. Пользователь видит то, что актуально для конкретной страны.

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

• Со страницей товара интереснее. Если товара нет в регионе, пользователь видит уведомление и возвращается на главную страницу.

Корзина остаётся одной для двух регионов. Магазин работает в Индии и Турции, и у пользователя в корзине могут лежать товары из обоих регионов одновременно. Но мы не делаем два отдельных запроса, а получаем все данные сразу. Поясним.

На сервере каждая карта пополнения хранится отдельной строкой, даже если это одна и та же карта, просто добавленная второй раз. На сайте же мы объединяем одинаковые карты в один пункт, а исходный ID сохраняем — чтобы кнопка «удалить» работала корректно. Это упрощает логику для пользователя и уменьшает количество запросов к серверу. Покупатель сразу видит, сколько товаров добавлено — ему не надо перемещаться между корзинами.

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

Этап 1: вёрстка интерфейсов по макетам

Первым делом мы взяли дизайн-макеты и начали вёрстку. Это был самый понятный этап, он занял пару недель.

Обычно сначала пишут бэкенд, а потом фронтенд. Мы пошли другим путём: начали вёрстку, ещё не зная, как будет устроен бэкенд. Использовали моковые данные, то есть заглушки. Это не случайное решение: на счету был каждый день.

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

Этап 2: подключение API и параллельная разработка

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

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

Этап 3: блог и админка на Payload CMS

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

Для него мы сделали уже не только фронтенд, но и бэкенд. Выбрали Payload CMS — современную гибкую систему, которая позволяет удобно управлять контентом без навыков кодирования.

Интересный момент: сначала мы выбрали TinaCMS. Она подкупила нас удобным live-редактором — изменения в контенте видны в реальном времени. Но в процессе работы выяснилось, что для нашей задачи это не главное. Основная работа, то есть встраивание товаров в статьи, в Tina требовала больше ручных доработок.

Так что мы переписали всё на Payload — там задачи решались сильно быстрее. А в визуальном редакторе можно настраивать интеграции без участия разработчиков.

• Основа всего — React и TypeScript. React отвечает за интерфейс, TypeScript — за типизацию и надёжность.

• На эту основу мы поставили Next.js — фреймворк, который даёт серверный рендеринг и дружелюбность к SEO.

• Для управления состоянием приложения, например, фильтрами в каталоге или данными корзины, использовали Jotai.

Бэкенд блога: Payload CMS.

Главная техническая изюминка:

Бэкенд блога — отдельный, но он подтягивает часть данных с основного бэкенда. Например, списки игр, которые уже есть в основной системе.

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

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

Как мы проектировали на ходу и без ТЗ

Это, наверное, самая интересная часть проекта. У нас не было технического задания — только макеты и общее понимание задачи. Точнее, у нас было ТЗ, но только на блог.

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

Такой подход нам особенно нравится. Когда нет готового ТЗ, мы ещё больше чувствуем своё влияние на продукт: каким он будет и какую пользу принесёт.

Что нам это дало:

• Мы лучше поняли бизнес-логику клиента.

• Клиент получил сайт, который решает его задачи и задачи пользователя, а не просто сделан по ТЗ.

• Мы прокачали навыки работы в условиях неопределённости.

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

Мы продолжаем развивать проект — помогаем с SEO и мелкими правками. А это значит, что клиент доволен.

Что в итоге

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

Это сложный проект. Но именно такие и заставляют нас расти.