Электроника и DIY — это каталоги, где сложность не в дизайне, а в количестве. Десятки тысяч SKU, у каждого — десятки технических атрибутов (мощность, разъём, типоразмер, совместимость, класс защиты), множество вариантов и быстро меняющиеся остатки. Бизнес-результат, за который борется такой магазин, измеряется одной цифрой: за сколько миллисекунд покупатель доходит от поискового запроса до нужной карточки. Чем дольше грузится выдача с фильтрами, тем выше отказы и ниже конверсия. Ниже — открытый разбор того, что на эту задачу даёт Saleor. Это не кейс KT.Team, а обзор возможностей платформы с опорой на официальную документацию и исходный код.
Почему Saleor подходит под большой технический каталог
Saleor — open-source headless-платформа коммерции под лицензией BSD-3-Clause, с единственным API на GraphQL (github.com/saleor/saleor). Для каталога электроники важны три встроенных свойства.
Первое — гибкая товарная модель. Товары описываются через типы, атрибуты и метаданные, которые задаются динамически. Атрибуты создаются независимо от типов товара, и для каждого можно отдельно управлять видимостью в фасетном поиске и на карточке (docs.saleor.io/developer/attributes/api). Это значит, что «напряжение», «тип резьбы» или «класс энергоэффективности» — не хардкод, а конфигурируемые сущности, которые сразу становятся осями фильтрации.
Второе — multichannel. Saleor нативно поддерживает несколько каналов продаж с раздельными ценами и доступностью на канал. Для DIY-сети с разными регионами и валютами это снимает необходимость дублировать каталог.
Третье — API-only архитектура. Бэкенд отдаёт данные только через GraphQL, что соответствует подходу «минимально трогаем ядро инструмента»: бизнес-логику и витрину строят рядом, не форкая платформу.
Где у Saleor граница и зачем выносить поиск
Здесь важна честность. Фильтрация в самом Saleor работает через GraphQL-механизм `where` (он заменил старый `filter`): поддерживает операторы `AND`/`OR`, операции `eq` и `oneOf`, фильтрацию по атрибутам через slug и пагинацию (docs.saleor.io/api-usage/filtering). Этого достаточно для аккуратных каталожных запросов. Но полнотекстовый поиск в Saleor — это отдельный корневой аргумент `search`, а полноценный фасетный поиск с подсчётом значений и sub-second откликом на десятках тысяч SKU документация прямо рекомендует выносить во внешний движок (Elasticsearch или Algolia) через Saleor Apps. Это и есть «read before you write»: не изобретать поисковый индекс поверх реляционной БД, а взять зрелый специализированный стандарт.
Saleor Search App: индекс, который сам остаётся актуальным
У Saleor есть официальное Search App для интеграции с Algolia (docs.saleor.io/developer/app-store/apps/search). Что оно делает на практике:
- Индексирует товары, категории и страницы и позволяет искать их через API Algolia. Каждый вариант товара становится отдельной записью в индексе — для электроники с её вариативностью это правильная гранулярность.
- Создаёт отдельные индексы на канал по схеме `PREFIX.CHANNEL_SLUG.CURRENCY_CODE.products`, так что цена и доступность в выдаче всегда соответствуют конкретному каналу.
- Преднастраивает фасеты по типу товара, категориям, ценовым диапазонам и наличию — то есть базовая фильтрация витрины работает «из коробки».
- Синхронизируется через webhooks: при создании и изменении товара, изменении остатков варианта, правках категорий и страниц индекс обновляется автоматически, без ручных прогонов.
Так возникает разделение ответственности: Saleor — источник истины по товарам и атрибутам, Algolia — слой быстрого поиска и фасетов. Витрина (например, на Next.js) обращается к поисковому движку для выдачи и фильтров и к Saleor — за детальной карточкой и оформлением заказа. Это loosely coupled, отчуждаемая архитектура: поисковый слой можно заменить (Algolia → Elasticsearch/Typesense) без переписывания ядра.
Подводные камни, которые видно заранее
Открытый разбор обязан назвать ограничения. Algolia держит лимит на размер записи (порядка 10 КБ). Товары электроники с длинными описаниями и большим числом атрибутов могут его превышать. Search App решает это конфигурируемой фильтрацией полей: ненужные в поиске поля (полное описание, тяжёлые метаданные, URL медиа) отключают, чтобы уложиться в лимит. Первичный массовый импорт запускается вручную и должен завершиться при открытой панели — это разовая операция при запуске, которую стоит планировать. Наконец, разнесение каталога на индексы по каналам означает рост числа индексов — это нормально, но требует учёта в тарифах поискового движка.
Бизнес-результат и схема процесса
Связка «Saleor + внешний поисковый движок» нацелена на один измеримый эффект: путь от запроса к карточке сокращается до долей секунды даже на каталоге в десятки тысяч SKU, потому что фасетная выдача обслуживается индексом, а не реляционными запросами на лету. Параллельно бизнес получает отчуждаемость (поисковый слой меняется без замены платформы) и автоматическую актуальность выдачи за счёт webhook-синхронизации.
Takeaway по процессу каталогизации и поиска. Перестройте процесс по принципу разделения слоёв: (1) контент-менеджер ведёт товары и атрибуты только в Saleor как единственном источнике истины; (2) webhook автоматически отправляет изменения в поисковый индекс — никаких ручных выгрузок; (3) витрина берёт фасетную выдачу из поискового движка, а карточку и checkout — из Saleor. Тогда «ускорение пути от запроса к карточке» становится не разовой оптимизацией, а свойством самого процесса: каждое изменение каталога автоматически попадает в быстрый поиск, а скорость выдачи не деградирует с ростом числа SKU.
