За полтора месяца собрал панель управления заказами на react-admin для интернет-магазина одежды, где заказы приходили из трёх источников: сайт на WooCommerce, звонки в call-центр и заявки через Telegram-бота. Штатная админка WooCommerce с этим потоком не справлялась - менеджеры путали статусы, трек-номера СДЭК терялись в комментариях к заказу, а бухгалтер каждый месяц вручную сверял платежи T‑Bank с базой. Ниже - архитектура кейса: как я спроектировал дата-слой, разграничил роли и завязал автоматику на n8n, чтобы заказ проходил путь от оплаты до доставки без пересылки скриншотов в чатах.
Зачем магазину понадобилась своя система управления заказами
Клиент вёл 40-60 заказов в день суммарно с сайта, соцсетей и оптовых клиентов по телефону. Часть заказов создавалась прямо в WooCommerce, часть - вручную менеджером после звонка, а данные о доставке жили в личном кабинете СДЭК отдельно от всего остального. Когда покупатель писал “где мой заказ”, менеджер открывал три вкладки и ещё Excel с оптовыми отгрузками.
Рассматривали три варианта: доработать WooCommerce плагинами, взять готовый no-code конструктор вроде Retool и написать кастомную панель с нуля. Плагины упирались в лимиты WooCommerce REST API и криво работали с оптовыми заказами, которых в самом WooCommerce не было вообще. No-code решал задачу на 70%, но клиенту нужны были специфичные статусы (“передан на упаковку”, “ждёт предоплату от опта”) и бизнес-правила, которые в конструкторе превращались в нечитаемую кашу из условий. В итоге выбрали react-admin - фреймворк даёт готовый слой CRUD, авторизацию и роутинг из коробки, а всю бизнес-логику пишешь как обычный React-код, без плясок вокруг чужого UI-конструктора.
Стек и архитектура дата-провайдера в react-admin
Backend собрал на Laravel - он же отдаёт REST API для панели и держит вебхуки от WooCommerce и СДЭК. React-admin в этой схеме не лезет напрямую в базу WooCommerce, а работает только со своей нормализованной таблицей orders, куда данные попадают через синхронизацию. Это осознанное решение: если WooCommerce API отвалится или поменяет формат ответа, панель менеджеров продолжит работать с уже загруженными заказами.
Ключевой момент архитектуры - кастомный dataProvider. React-admin из коробки ждёт единый REST-контракт (getList, getOne, update и так далее), а у меня заказы, платежи и трек-статусы лежали в разных таблицах с разными форматами пагинации. Написал обёртку, которая приводит ответы Laravel к формату, понятному react-admin:
const ordersDataProvider = {
getList: async (resource, params) => {
const { page, perPage } = params.pagination;
const { field, order } = params.sort;
const query = new URLSearchParams({
page,
per_page: perPage,
sort_field: field,
sort_order: order,
...params.filter,
});
const { data } = await httpClient(`/api/${resource}?${query}`);
return {
data: data.items,
total: data.meta.total,
};
},
update: async (resource, params) => {
const { data } = await httpClient(`/api/${resource}/${params.id}`, {
method: 'PUT',
body: JSON.stringify(params.data),
});
return { data };
},
};Такой слой абстракции экономит время на любом следующем экране: под платежи, отгрузки или возвраты не пишешь новый API-клиент, а просто регистрируешь ресурс с тем же dataProvider.
Как завели заказы из WooCommerce и трек СДЭК в одну ленту
Синхронизация с WooCommerce построена на связке cron-задачи и вебхука. Вебхук ловит создание и изменение заказа в реальном времени (WooCommerce умеет слать их из коробки через Settings → Advanced → Webhooks), а cron раз в 15 минут подчищает расхождения - если вебхук не долетел из-за таймаута хостинга, что на практике случается пару раз в неделю.
С СДЭК история сложнее: их API отдаёт статус по номеру заказа, но не пушит изменения сам. Поставил очередь задач в Laravel, которая раз в час опрашивает статусы активных отправлений и обновляет поле tracking_status в таблице orders. В react-admin это поле показывается как цветной бейдж прямо в списке заказов - менеджеру не нужно открывать карточку, чтобы понять, где посылка.
Оплаты подтягиваются из T‑Bank по вебхуку на успешный платёж: событие пишет payment_id и сумму в заказ, и в панели автоматически проставляется статус “оплачен”. Раньше это делала бухгалтер руками в конце месяца, сверяя выписку с заявками - сейчас расхождения видно сразу, потому что заказ без привязанного платежа явно выделен в фильтре.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Права доступа и кастомные компоненты в панели
Роли и видимость данных
react-admin через authProvider позволяет завязать интерфейс на роль пользователя без переписывания роутов. Сделал три роли: менеджер видит только заказы, оптовик - оптовые сделки и свою сумму задолженности, бухгалтер - вкладку с платежами и экспортом в 1С. Проверка прав идёт и на фронте (скрытие пунктов меню), и на бэке (Laravel Policy на каждый эндпоинт) - полагаться только на скрытие кнопок в интерфейсе небезопасно, доступ всегда режется на сервере.
Кастомные поля и статусы
Стандартный Datagrid из react-admin хорошо показывает таблицы, но статус заказа нужен был не текстом, а цветным индикатором с иконкой этапа: новый, в обработке, передан в СДЭК, доставлен, возврат. Написал компонент OrderStatusField поверх стандартного FunctionField, а массовые действия (bulk actions) добавил через кастомную кнопку в тулбаре списка - например, “передать в СДЭК пачкой” для отобранных чекбоксами заказов вместо перехода в каждую карточку отдельно.
Уведомления и автоматизация статусов заказов
Самая ощутимая экономия времени для клиента вышла не из самой панели, а из автоматики вокруг неё. Изменение статуса заказа в react-admin бьёт вебхуком в n8n, развёрнутый на сервере в РФ - контакты покупателей и переписка с ними не должны уходить в зарубежные облака по 152-ФЗ, поэтому и n8n, и база заказов стоят на отечественном хостинге.
n8n-сценарий разбирает статус и решает, кому и куда слать уведомление: покупателю - сообщение в Telegram через aiogram-бота (“ваш заказ передан в СДЭК, трек такой-то”), менеджеру - пуш, если заказ провисел без движения больше суток. Шаблон такого workflow под статусную модель заказов я обычно беру за основу из библиотеки готовых сценариев автоматизации и дорабатываю под конкретный набор статусов клиента - быстрее, чем собирать граф нод с нуля каждый раз.
Отдельно завели авто-эскалацию: если оплаченный заказ не переведён в статус “передан на сборку” за 3 часа в рабочее время, n8n шлёт напоминание в общий чат менеджеров. За первый месяц работы панели количество заказов, зависших без движения дольше суток, упало примерно в четыре раза - просто потому что о них перестали забывать.
Сроки, стоимость и подводные камни разработки
На проект ушло шесть недель: неделя на проектирование дата-модели и ролей, три на панель и дата-провайдер, две на интеграции и автоматизацию с параллельным тестированием на реальных заказах клиента. Для похожей задачи - CRM или админ-панель на React с интеграциями - у меня цена стартует от 100 000 ₽, итоговая сумма зависит от числа внешних систем и сложности бизнес-правил по статусам.
Главная ловушка таких проектов - недооценить объём работы на нормализации данных из внешних источников. Сама панель на react-admin пишется быстро, а вот привести WooCommerce, СДЭК и T‑Bank к единой модели заказа, обработать дубли и рассинхроны - это где реально уходит время. На рынке за похожую задачу студии часто просят 200 000-400 000 ₽ именно потому, что закладывают риск на доработку интеграций постфактum.
| Подход | Срок запуска MVP | Гибкость под нестандартные статусы | Что в итоге |
|---|---|---|---|
| Кастомная панель на react-admin | 4-6 недель | Высокая - любая бизнес-логика на React | Полный контроль, требует бэкенд-разработки |
| No-code конструктор (Retool и аналоги) | 1-2 недели | Средняя - упирается в лимиты конструктора | Быстрый старт, сложные сценарии превращаются в кашу |
| Доработка плагинами поверх WooCommerce | 2-3 недели | Низкая - завязано на чужую архитектуру плагина | Дёшево на старте, дорого на масштабировании |
Ещё один момент, который стоит закладывать заранее - обучение менеджеров. Даже удобный интерфейс требует адаптации: в первую неделю после запуска я обычно держу канал поддержки открытым, чтобы быстро поправить формулировки статусов и добавить недостающий фильтр по свежим отзывам от тех, кто с панелью работает каждый день.
Кастомный CRM/админ-интерфейс
Админка / CRM
от 100 000 ₽
Подробнее →Частые вопросы
Сколько стоит разработка панели управления заказами на react-admin?
Цена зависит от количества источников заказов и сложности бизнес-правил. Разработка CRM или админ-панели на React у меня стартует от 100 000 ₽ - в эту сумму входит дата-провайдер, роли доступа и базовые списки/карточки. Интеграции с внешними системами вроде СДЭК или эквайринга считаются отдельно, обычно как комплексная интеграция от 40 000 ₽ за каждую систему в зависимости от сложности их API.
Чем react-admin лучше готовых no-code админок вроде Retool?
No-code быстрее на старте, но упирается в потолок, как только появляются нестандартные статусы, вложенная логика прав или массовые действия с условиями. react-admin - это обычный React-проект: любую бизнес-логику пишешь кодом, без обхода ограничений визуального конструктора, и легче переиспользовать компоненты между разными разделами панели.
Можно ли подключить к панели СДЭК и T‑Bank без доступа к исходному коду интернет-магазина?
Да, если у площадки есть открытое REST API или вебхуки - WooCommerce, Bitrix и большинство коробочных CMS их отдают. Панель в этом случае работает как отдельный слой поверх магазина: подключается через API-ключи, не трогая ядро сайта, и синхронизирует данные в свою базу.
Нужна ли отдельная база данных или можно работать поверх WooCommerce?
В проектах с несколькими источниками заказов (сайт плюс звонки, плюс мессенджеры) отдельная нормализованная база почти всегда лучше - WooCommerce просто не рассчитан на заказы, которые в нём никогда не создавались. Если заказы приходят из одного источника и его схема данных устраивает, можно обойтись без дублирования и подключить react-admin напрямую к API площадки.