Магазин на Saleor и Next.js: когда такой подход оправдан
Saleor с Next.js стоит рассматривать, когда магазину нужны собственная витрина, особые правила продажи и интеграции. Это проект с разработкой и постоянным обслуживанием. Начните с десяти товаров и одного учебного заказа: подтвердите цену, оплату и передачу менеджеру, прежде чем рассчитывать на рабочий запуск.
Что подготовить
- Десять учебных товаров, включая варианты комплектации, нулевой остаток и изменение цены.
- Правила продажи: кто ведёт цены и остатки, как считается доставка и кто принимает заказ.
- Тестовая оплата без реальных денег; разработчик витрины и ответственный менеджер.
Что готово, а что ещё нужно разработать #
Компания продаёт оборудование с вариантами комплектации. Первый шаг — описать один заказ: модель, комплект, количество, контакт, адрес, доставка и оплата. Если цену каждый раз считает менеджер, сначала может быть полезнее каталог с заявкой, чем полный автоматический магазин.
Saleor управляет каталогом и заказами, а Next.js создаёт витрину для покупателя. API — способ, которым программы обмениваются данными; Saleor использует GraphQL — язык запросов к этим данным. Между ними нужен код конкретного проекта: страницы, корзина, ошибки и действия пользователя.
Официальный шаблон витрины помогает начать, но его нужно проверить и адаптировать. Работающий сервер и открывающийся сайт ещё не подтверждают готовность продажи. Команда проекта отвечает за свою витрину и её совместимость с выбранным API.
Страницы покупателя. Каталог, комплектация, корзина и оформление должны соответствовать правилам компании.
Внешние сервисы. Нужные способы оплаты, доставки и документы подтверждают отдельно. Они не считаются готовыми из-за самого факта установки Saleor.
Работа менеджера. Определите, когда заказ поступает в работу и что происходит при ошибке. Данные в панели должны вести к понятному действию.
Какие правила нужны каталогу #
| Решение | Вопрос владельцу магазина |
|---|---|
| Товар и вариант | Чем отличается продаваемая комплектация и как её идентифицировать |
| Цена | Откуда приходит и кто подтверждает изменение |
| Остаток | Где источник истины и когда количество уменьшается |
| Канал продажи | Какие валюта, ассортимент и правила доступны покупателю |
| Доставка | Кто рассчитывает стоимость и какие адреса поддерживаются |
| Заказ | Когда менеджер принимает его в работу и что получает клиент |
Товар и его продаваемый вариант — разные элементы. Один прибор с пятью комплектациями не нужно случайно превращать в пять несвязанных карточек. Артикул, изображение, цена и доступность должны соответствовать варианту, который покупатель выбрал.
В таблице выше — решения владельца магазина до настройки. На десяти товарах включите простой товар, несколько вариантов, недоступный товар, нулевой остаток и изменённую цену. Так каталог проверяется по рабочим случаям, а не только по заполнению полей.
Если цены и остатки ведутся в другой системе, выберите главное место их изменения. Интеграция — настроенный обмен между системами. Нужны соответствие идентификаторов, журнал ошибок, повторы и сверка; наличие API не создаёт это автоматически.
Два сотрудника не должны менять одну цену в разных системах без правила разрешения конфликта. Укажите ответственного за расхождение: он должен понять, какие данные верны и как исправление попадёт на витрину.
Когда заказ действительно оплачен #
Checkout — оформление до создания заказа. Покупатель выбирает количество, вводит данные и проходит выбранный процесс. Оплата учитывается отдельно через транзакции и события платёжного сервиса. Возвращение браузера на страницу магазина ещё не подтверждает получение денег.
Выберите платёжный сервис и найдите подходящее приложение для Saleor. Если готового приложения нет, посчитайте стоимость разработки. Отдельно решите с бухгалтером и разработчиком, как проводить возвраты, сверять деньги и оформлять нужные кассовые документы.
Один источник подтверждения. Зафиксируйте, каким событием система подтверждает успешную оплату и кто проверяет спорный результат.
Повтор события. Повторное сообщение провайдера не должно второй раз отправить один заказ на склад или породить лишнее подтверждение.
Ошибка. Нужен безопасный повтор обработки или ручная очередь с владельцем. Потерянный заказ не должен оставаться только записью в техническом журнале.
Проверяйте оплату в песочнице — тестовом режиме провайдера без реальных денег. Закрытие окна, отказ и позднее уведомление должны иметь ожидаемый результат для покупателя и менеджера. Это требования к интеграции вашего проекта.
Как разделить работу и ответственность #
В смете отделите возможности Saleor без изменений, адаптацию витрины и собственные интеграции. Например, каталог опирается на Saleor, страница комплекта — на витрину, передача заказа в учёт — на обмен. Руководитель увидит, кто отвечает за каждую часть.
Saleor Apps — приложения расширения платформы через API и события. Каждому нужны свои права, настройки и обслуживание. Выдавайте только необходимые полномочия; секретные ключи не помещайте в код страницы, который получает браузер покупателя.
Если CRM или уведомления подключаются вашим обработчиком, прямо учитывайте разработку и её поддержку. Нельзя считать связь готовой только потому, что оба сервиса установлены. Проверка должна пройти от события заказа до нужного результата во внешней системе.
Откройте страницу товара и проверьте название, описание, цену и изображения. Разработчик должен убедиться, что поисковик тоже получает содержание страницы. На телефоне покупатель должен легко выбрать товар и оформить заказ; сохранённые страницы не должны показывать устаревшую цену.
Что проверить до рабочего запуска #
Учебный заказ до запуска
- Покупатель выбирает комплектацию и количество; итоговая цена с доставкой совпадает с контрольным расчётом.
- После добавления в корзину измените цену или наличие. Проверьте понятное сообщение и подтверждение нового итога.
- В песочнице пройдите оплату, отказ, закрытие окна и повтор события. Сверьте заказ и уведомления отдельно.
- Отмените учебный заказ, выполните нужную тестовую операцию возврата и проверьте передачу в учёт.
- Проверьте телефон, поиск, заголовки страниц, права и восстановление. Для каждого исключения запишите владельца и способ обработки.
Эти проверки нужны до рабочего запуска. Для каждого неприятного случая заранее запишите, что увидит покупатель, кто получит ошибку и как продолжится работа. Так приёмка даёт ответ владельцу бизнеса, а не только список технических событий.
Заказ в панели — лишь часть результата. Сверьте идентификаторы, суммы и состояния между Saleor, платёжным сервисом и системой учёта. Если они расходятся, назовите ответственного и способ исправления до подключения настоящих покупателей.
Когда такой магазин оправдан #
Saleor с Next.js оправдан, если собственная витрина и интеграции дают понятный выигрыш, а компания выделяет бюджет на разработку и обслуживание.
Рассмотрите готовый магазин, если нужны типовые товары и стандартное оформление. Сравните время запуска и постоянные расходы, а не число компонентов.
Начните с каталога и заявки, если продажа пока требует ручного расчёта. Полную автоматизацию можно оценить после уточнения процесса.
Постоянные расходы включают витрину, API, фоновые процессы, базу, файлы, копии и мониторинг. Платёжные и доставочные сервисы имеют отдельные условия. Обновления приложений и совместимость обмена тоже входят в работу, а не исчезают после запуска.
Открытый код не включает коммерческое облако, поддержку и локальные сервисы. Назначьте владельца заказа как бизнес-процесса и технического ответственного. Оба должны знать, где обнаруживаются ошибки и как вернуть процесс в рабочее состояние.
Как понять, что можно двигаться дальше
- Цена, вариант и доступность проверены на учебном каталоге; изменения объясняются покупателю.
- Оплата, отказ, повтор и отмена имеют согласованный результат в Saleor и внешних системах.
- В смете разделены готовые функции, витрина и интеграции; владельцы заказа и технического обслуживания определены.