Розробка кабінету та вітрини продавця для маркетплейсу
Особистий кабінет продавця — один з ключових модулів маркетплейсу. Від його зручності безпосередньо залежить, як швидко продавці заповнюють каталог, обробляють замовлення та керують своєю присутністю на платформі. Поганий кабінет — це onboarding довжиною в тиждень, постійні звернення в підтримку та відтік постачальників.
Архітектура модуля
Кабінет продавця — це окремий SPA або набір сторінок, ізольованих від купівельної частини. Працює в межах тієї ж Laravel/Node.js кодової бази, але через окремий middleware-стек з перевіркою ролі seller та прив'язкою до конкретного shop_id.
Основні розділи:
- Дашборд з ключовими метриками (виручка, кількість замовлень, конверсія, рейтинг)
- Управління товарами: створення, редагування, масовий імпорт через Excel/CSV
- Управління замовленнями: статуси, трекінг, формування етикеток
- Фінанси: баланс, історія виплат, запит на виведення коштів
- Налаштування магазину: опис, логотип, політики повернення, робочі години
Вітрина продавця (публічна сторінка)
Публічна вітрина — це /shop/{slug} з підбором товарів, інформацією про продавця та блоком рейтингу. Генерується на сервері для SEO. Включає:
- Агреговані дані: середній рейтинг, кількість рецензій, відсоток виконання
- Фільтрацію та пошук у магазині
- Кнопку підписки на магазин (для повторних покупок)
- Блок останніх рецензій з відповідями продавця
Управління товарами
Форма створення товару — складний компонент з залежними полями. Набір атрибутів змінюється залежно від категорії (для електроніки — гарантія та характеристики, для одягу — розмірна сітка та склад). Реалізується через динамічну схему атрибутів, збережену в базі.
category_attributes (category_id, attribute_name, type, required, options)
product_attribute_values (product_id, attribute_id, value)
Масовий імпорт через чергу: файл завантажується на S3, завдання розбирає його побудрядково, створює товари та фото, звіт про помилки повертається продавцю через email або UI.
Дашборд — метрики в реальному часі
Дані дашборду не будуються за запитом — занадто дорого. Використовується матеріалізація:
- Таблиця
seller_statsоновлюється раз на годину через scheduled job - Дані за поточний день розраховуються live через Redis-лічильники
- Графіки будуються на основі
order_daily_aggregates— таблиці з передагрегованими даними по дням
Для візуалізації підходить Recharts або Chart.js. Компонент дашборду отримує дані через окремий API-endpoint, не змішуючи їх з основним CRUD.
Обробка замовлень продавцем
Продавець бачить тільки замовлення, які містять його товари. Інтерфейс обробки:
- Підтвердження замовлення (перехід у статус
confirmed, сповіщення покупцю) - Передача в доставку: введення track-номера або виклик API служби доставки
- Відмітка відправки: статус
shipped, автоматичний email покупцю - Обробка повернень: запит повернення від покупця → рішення продавця → фінансова операція
Кожний перехід статусу логується в order_status_history з timestamps та actor_id.
Права доступу в межах кабінету
У великого продавця може бути команда. Потребує система ролей у межах магазину:
| Роль | Товари | Замовлення | Фінанси | Налаштування |
|---|---|---|---|---|
| Власник | R/W | R/W | R/W | R/W |
| Менеджер | R/W | R/W | R | — |
| Склад | R | R/W | — | — |
Реалізується через Spatie Laravel Permission з tenant-scope: shop_id прив'язується до кожної ролі.
Технічний стек та строки
Backend: Laravel з Eloquent, Gate/Policy політики, Redis/Horizon черги Frontend: React з React Hook Form, TanStack Query, компоненти Shadcn/ui Зберігання файлів: S3 (MinIO для self-hosted), генерація presigned URL для завантаження прямо з браузера
Базовий кабінет (товари + замовлення + дашборд без складної аналітики) — 3–4 тижні розробки. Повний модуль з масовим імпортом, ролями в команді та фінансовим розділом — 6–8 тижнів.