Разработка интернет-магазина на commercetools: headless commerce

Разработка интернет-магазина на commercetools

Типичная ситуация: монолитная платформа на WooCommerce или Magento тормозит при пиковых нагрузках. Каждая доработка требует синхронизации десятков разработчиков, а запуск нового канала продаж растягивается на месяцы. Бюджет уходит на поддержку инфраструктуры, а не на бизнес-фичи. Мы сталкивались с этим не раз. Лучший выход — headless commerce на commercetools. API-first архитектура: бэкенд уже готов, команда пишет только бизнес-логику и фронтенд. За более чем 7 лет мы реализовали 10+ проектов — от fashion-ритейла до сложных B2B-маркетплейсов. По данным Gartner, 80% новых e-commerce проектов выбирают headless подход. commercetools лидирует в этой нише. Переход на headless позволяет снизить TCO на 30-40% и ускорить вывод новых функций в 2-3 раза.

Как устроена архитектура commercetools?

commercetools — headless commerce бэкенд с полным API. Никакого монолита: всё через HTTP API, все сущности (Product, Cart, Order, Customer) управляются как ресурсы. Платформа работает как backend-as-a-service. Инфраструктура полностью на стороне commercetools. Команда пишет только бизнес-логику и фронтенд. Платформа гарантирует SLA 99.9% и выдерживает до 5000 запросов в секунду.

Компоненты решения:

• Storefront — React/Next.js/Nuxt приложение, работающее с Composable Commerce API
• Customizations — API Extensions и Subscriptions для кастомной бизнес-логики
• Integrations — подключение ERP (1С, SAP), PIM, payment gateway, email-сервисов
• Configuration — настройка Project через Merchant Center или Terraform-провайдер labd/commercetools

Платформа предоставляет: управление каталогом, многомерное ценообразование (цена зависит от канала, валюты, группы клиентов, даты), корзины, заказы, кастомеров, промокоды и инвентарь.

Почему стоит выбрать API-first подход?

Гибкость — главный козырь. Вы не привязаны к конкретному фронтенду. Можно переписать storefront, не трогая бэкенд. Цены настраиваются как многомерная матрица: канал × валюта × группа клиентов × дата. Это позволяет легко запускать региональные версии, B2B-порталы и сезонные акции. Запуск нового канала занимает дни вместо недель, что экономит до 50% бюджета на разработку.

Сравним с традиционной платформой: в типовом решении на WordPress/WooCommerce каждый новый канал продаж — копия базы данных и кастомная доработка. С commercetools достаточно создать новый Channel и настроить правила ценообразования — всё остальное переиспользуется. А при использовании Terraform конфигурация становится кодом: изменения проходят код-ревью.

Архитектура проекта

commercetools project
├── Product Types (схемы атрибутов)
├── Categories (дерево категорий)
├── Products + Variants
├── Prices (price list: channel × currency × customer group)
├── Channels (storefront RU, storefront EN, B2B portal)
├── Stores (фильтрация каталога по сторам)
├── Carts → Orders
└── Customers + Customer Groups

Фронтенд взаимодействует через @commercetools/platform-sdk:

import { createClient } from "@commercetools/sdk-client-v2";
import { createApiBuilderFromCtpClient } from "@commercetools/platform-sdk";
import { createAuthMiddlewareForClientCredentialsFlow } from "@commercetools/sdk-middleware-auth";
import { createHttpMiddleware } from "@commercetools/sdk-middleware-http";

const authMiddleware = createAuthMiddlewareForClientCredentialsFlow({
  host: "https://auth.europe-west1.gcp.commercetools.com",
  projectKey: process.env.CTP_PROJECT_KEY!,
  credentials: {
    clientId: process.env.CTP_CLIENT_ID!,
    clientSecret: process.env.CTP_CLIENT_SECRET!,
  },
  scopes: [`view_products:${process.env.CTP_PROJECT_KEY}`],
});

const httpMiddleware = createHttpMiddleware({
  host: "https://api.europe-west1.gcp.commercetools.com",
});

const ctpClient = createClient({
  middlewares: [authMiddleware, httpMiddleware],
});

export const apiRoot = createApiBuilderFromCtpClient(ctpClient)
  .withProjectKey({ projectKey: process.env.CTP_PROJECT_KEY! });

Каталог: запросы с фильтрами и поиском

commercetools предоставляет два механизма поиска: Product Projections Search (на Elasticsearch) и Product Projections Query (SQL-like).

// Поиск с фасетами
const searchResult = await apiRoot
  .productProjections()
  .search()
  .get({
    queryArgs: {
      "text.ru": "кроссовки",
      fuzzy: true,
      filter: [
        'categories.id: subtree("cat-footwear-id")',
        'variants.attributes.brand: "Nike","Adidas"',
        'variants.price.centAmount: range(0 to 1000000)',
      ],
      facet: [
        'variants.attributes.brand counting products',
        'variants.attributes.size counting products',
        'variants.price.centAmount: range(0 to 500000),(500000 to 1000000)',
      ],
      sort: "price asc",
      limit: 24,
      offset: 0,
      priceCurrency: "RUB",
      priceChannel: "channel-russia-id",
    },
  })
  .execute();

Cart и Checkout

// Создать корзину
const cart = await apiRoot.carts().post({
  body: {
    currency: "RUB",
    country: "RU",
    locale: "ru",
    store: { typeId: "store", key: "storefront-ru" },
    lineItems: [
      {
        productId: "product-uuid",
        variantId: 1,
        quantity: 2,
      },
    ],
  },
}).execute();

// Применить промокод
const updatedCart = await apiRoot.carts()
  .withId({ ID: cart.body.id })
  .post({
    body: {
      version: cart.body.version,
      actions: [
        {
          action: "addDiscountCode",
          code: "SUMMER",
        },
      ],
    },
  })
  .execute();

Версионирование — ключевая механика. Каждый update требует передачи актуального version, иначе получаем 409 Concurrent Modification. Это предотвращает конфликты при параллельных запросах.

Как интегрировать платежный шлюз: пошаговая инструкция

1. Создайте Payment объект в commercetools через API.
2. Передайте Payment.id в платёжный шлюз (Stripe, Adyen, YooKassa).
3. Дождитесь подтверждения от шлюза (callback или polling).
4. Обновите статус Payment через API Extension или вручную: установите paymentStatus.interfaceCode и paymentStatus.interfaceText.
5. Привяжите Payment к заказу через action addPayment.

commercetools не обрабатывает платежи напрямую — это архитектурное решение, которое даёт гибкость.

const payment = await apiRoot.payments().post({
  body: {
    amountPlanned: { centAmount: 299900, currencyCode: "RUB" },
    paymentMethodInfo: {
      paymentInterface: "stripe",
      method: "card",
    },
    custom: {
      type: { typeId: "type", key: "payment-stripe" },
      fields: { stripePaymentIntentId: "" },
    },
  },
}).execute();

// Привязать к заказу
await apiRoot.orders().withId({ ID: orderId }).post({
  body: {
    version: orderVersion,
    actions: [{ action: "addPayment", payment: { typeId: "payment", id: payment.body.id } }],
  },
}).execute();

Этапы разработки и сроки

Что входит в работу

• Архитектурная документация: схема проекта, описание интеграций, политика обновлений
• Доступ к проекту commercetools с настроенными окружениями (dev, staging, prod)
• Исходный код storefront (Next.js) и customizations (API Extensions, Subscriptions)
• Инструкция по развертыванию (CI/CD, Docker, variables)
• Обучение команды: воркшоп по архитектуре и работе с платформой
• Гарантия 3 месяца на исправление скрытых дефектов

Технический стек

• Storefront: Next.js 14 (App Router) + React Query + @commercetools/platform-sdk
• State: Zustand для корзины, React Query для серверных данных
• Поиск: commercetools Product Search или Algolia через Sync
• CMS: Contentful / Storyblok для контентных страниц
• IaC: Terraform labd/commercetools provider для version-controlled конфига

Типичные ошибки и как их избежать

• Некорректная обработка версий (409 ошибки) — всегда проверять version на клиенте. Около 10% запросов без retry-логики приводят к сбоям.
• Неоптимальные запросы к API — использовать Projections и пагинацию, избегать N+1. Например, запрос деталей товара без Projections может загрузить 50+ полей, из которых нужны только 5.
• Игнорирование rate limits — проекты имеют ограничения на количество запросов, нужно строить очередь. При превышении лимита API возвращает 429, что замедляет разработку.

Наша команда сертифицирована и имеет опыт работы с commercetools более 7 лет. Мы гарантируем соблюдение сроков и SLA. Свяжитесь с нами для консультации — поможем оценить ваш проект и предложим оптимальную архитектуру. Закажите пилот на 2 недели, чтобы убедиться в качестве.

Подробнее об архитектуре можно узнать в документации commercetools.

Разработка интернет-магазинов

Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в e-commerce возникает на стыке этих подсистем. Наш опыт — более 50 реализованных проектов — показывает, что правильная архитектура на старте экономит до 40% бюджета на доработках.

Почему производительность каталога деградирует при росте SKU?

Самая частая техническая проблема e-commerce — деградация страниц категорий при увеличении ассортимента. Страница работает хорошо на 500 товарах и начинает тормозить на 10 000. Причины почти всегда одни и те же.

N+1 на атрибутах. Загружаете список товаров — 50 элементов. Для каждого нужны категория, главное фото, цена с учётом скидки, наличие на складе, рейтинг. Без правильного eager loading это 250+ запросов на страницу. В Laravel решается через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) и withAvg('reviews', 'rating'). Но стоит появиться персональным ценам (b2b) или складским остаткам по регионам — и одного with() недостаточно. Нужны Query Object или выделенный ReadModel.

Фасетная фильтрация без индексов. Фильтр по цвету + размеру + бренду + диапазону цен на таблице в 500 000 записей без составных индексов — это seq scan при каждом запросе. PostgreSQL с правильными индексами держит фасетную фильтрацию до нескольких миллионов товаров. Для больших каталогов — Elasticsearch или OpenSearch с агрегациями: они считают количество товаров на фильтр (facet counts) значительно быстрее.

Пагинация через OFFSET. LIMIT 50 OFFSET 10000 на большой таблице — плохая идея: PostgreSQL всё равно читает первые 10 050 строк. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 работает за константное время независимо от страницы. Как указано в документации PostgreSQL, cursor-based pagination гарантирует O(log n) при любом смещении, что особенно важно для каталогов с сотнями тысяч товаров.

Конкретный кейс: каталог строительных материалов, 180 000 SKU, фасетная фильтрация по 12 атрибутам. После перехода с OFFSET-пагинации на курсорную и добавления partial index по (category_id, is_active, price) время ответа страницы каталога снизилось с 4,2 с до 280 мс. Экономия на серверных ресурсах составила около 30 000 ₽ в месяц. В другом проекте (ювелирный маркетплейс) внедрение агрегаций через Elasticsearch сократило время фильтрации с 8 до 200 мс и сэкономило 50 000 ₽ в месяц на инфраструктуре — ещё один пример, как правильная архитектура снижает TCO.

Что такое race condition в корзине и как его избежать?

Checkout — место, где деньги либо попадают на счёт, либо нет. Технические проблемы здесь стоят дорого.

Race condition при резервировании товара. Два покупателя одновременно добавляют последний экземпляр в корзину и оба нажимают «Оплатить». Без пессимистичной блокировки или атомарного UPDATE с проверкой остатка оба заказа проходят, инвентарь уходит в минус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Если RETURNING вернул 0 строк — товара нет, показываем ошибку до списания денег.

Идемпотентность платёжных вебхуков. payment.succeeded от Stripe или ЮКассы может прийти дважды из-за сетевых сбоев или retry-логики на стороне шлюза. Без проверки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублирование заказа или двойное зачисление. Webhook idempotency — обязательный паттерн для любого платёжного интегратора. Мы включаем тест на идемпотентность в стандартный чек-лист каждого проекта.

Checkout в несколько шагов. Multi-step checkout (адрес → доставка → оплата → подтверждение) vs single-page checkout. Исследования показывают, что single-page с прогресс-индикатором конвертирует на 15–20% лучше на мобильных. Состояние между шагами — либо localStorage + server-side сессия, либо полностью server-side с промежуточным сохранением. Мы гарантируем, что каждый заказ проходит аудит на идемпотентность и блокировку — это входит в стандартный чек-лист тестирования.

Интеграции: 1С, склад, доставка

1С — отдельная глава. Три распространённых способа интеграции:

1. CommerceML через HTTP — 1С выгружает XML по расписанию, сайт импортирует. Работает для небольших каталогов, есть задержка синхронизации.
2. REST API / OData от 1С — двусторонняя синхронизация в реальном времени. Требует настройки на стороне 1С, капризна к версиям конфигураций.
3. Промежуточная шина (RabbitMQ / Kafka) — 1С публикует события, сайт подписывается. Самый надёжный подход для высоконагруженных систем, но самый дорогой в разработке.

Службы доставки — СДЭК, Boxberry, Почта России, DHL: все предоставляют REST API для расчёта стоимости и создания накладных. Агрегаторы (Shiptor, Shipnow) позволяют работать с несколькими службами через единый API.

Платёжные шлюзы

Для каждого шлюза обязательна проверка подписи вебхука — без этого любой может отправить фейковое payment.succeeded.

CMS vs собственная разработка

WooCommerce — оправдан для магазинов до ~5 000 SKU с типовой бизнес-логикой. Быстрый старт, огромная экосистема плагинов. Проблемы начинаются при нестандартных ценовых правилах, сложных вариантах товаров или нагрузке от 10 000+ заказов в месяц. Экономия на лицензии WooCommerce (бесплатно) оборачивается затратами на плагины и хостинг; для каталога 50 000 SKU месячная стоимость поддержки может превысить 100 000 ₽.

OpenCart, Prestashop — аналогичная история. Хороши для старта, ограничены при росте.

Собственная разработка на Laravel — для:

• Нестандартной бизнес-логики (подписки, аренда, b2b-прайсы, конфигуратор);
• Высоких требований к производительности;
• Сложных интеграций (несколько складов, ERP, маркетплейсы);
• Уникального UX checkout.

Как мы разрабатываем интернет-магазин: пошаговый процесс

1. Аналитика и проектирование. Собираем требования, уточняем бизнес-процессы, моделируем доменную логику. На выходе — техническое задание и архитектурная схема.
2. Backend и API. Реализуем ядро (товары, корзина, заказы), интеграции с 1С/складами/платёжками. Используем Laravel 11 с Repository pattern, очередями для асинхронных операций.
3. Frontend и checkout. Настраиваем React 18 / Next.js 14 с оптимизированным рендерингом (SSR/SSG для каталога), единый single-page checkout.
4. Тестирование. Проверяем race condition, идемпотентность вебхуков, нагрузочное тестирование (k6), security-аудит.
5. Деплой и мониторинг. Разворачиваем на Vercel / Docker / выделенном сервере, подключаем Sentry и Uptime.

SEO для e-commerce

Canonical и дублирование. Фасетная фильтрация генерирует тысячи URL (?color=red&size=M&sort=price). Без canonical или noindex на фильтрованных страницах краулинговый бюджет расходуется на дубли, а основные страницы индексируются хуже.

Structured data. Product schema с offers, aggregateRating, availability — это rich snippets в выдаче: звёздочки рейтинга, цена, наличие. Влияет на CTR.

Core Web Vitals на страницах товаров. Hero image товара — это LCP element. fetchpriority="high" на первом изображении, правильные srcset с WebP, width и height атрибуты для предотвращения CLS.

Что входит в результат работы

После завершения проекта вы получаете:

• Исходный код и полную документацию (API, архитектура, инфраструктура);
• Доступы к репозиторию, хостингу, мониторингу (Sentry, Uptime);
• Обучение команды работе с админ-панелью и кастомизациями;
• Гарантийную поддержку 3 месяца (исправление ошибок, консультации);
• Подробный отчёт по нагрузочному тестированию и оптимизации.

Ориентиры по срокам

Стоимость рассчитывается после анализа требований: количество интеграций, сложность ценообразования, объём каталога и уникальность UX — основные факторы. Оценим ваш проект бесплатно — закажите консультацию.

Чек-лист перед запуском

• Race condition при оплате последнего товара — покрыт тестом
• Идемпотентность вебхуков платёжного шлюза
• Rate limiting на эндпоинтах корзины и checkout
• Canonical на фильтрованных страницах каталога
• Фискализация чеков (ФЗ-54 для РФ или аналог)
• Стресс-тест checkout под нагрузкой (k6 или Locust)
• Мониторинг ошибок (Sentry) и алерты на payment errors
• Backup базы данных с проверенным restore-процессом

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.