eCommerce эволюционирующий 🎆

В 2025 году маркетплейсы всё активнее поглощают классический eCommerce. Хотя вроде уже и нет 🤷‍♂️. Крупные игроки вроде DNS чувствуют себя довольно уверенно. Что же делать компаниям поменьше или тем, кто только хочет выйти на рынок электронной коммерции?

Важно понимать, что интернет-магазин — лишь малая часть сложной цепочки процессов, обеспечивающих путь товара от клика на сайте до получения покупателем. За этим стоит огромное количество бизнес-процессов, но давайте упростим.

🎬 Стартовый этап: готовое решение Представим компанию, которая уже пыталась развивать eCommerce. Новый менеджер решает снова попробовать, но без долгосрочной разработки. Он ищет варианты.

Сразу пропустим Tilda и прочие SaaS-решения — у них нет точек масштабирования. Мы с клиентом смотрим дальше, насколько это возможно в современных реалиях.

Начинаем с комбинации Битрикс + готовое решение. Можете критиковать, но качественно собранное готовое решение, поддающееся кастомизации, для старта вполне приемлемо. Особенно если учесть, что в него вложено около 1000 часов разработки, и маловероятно, что на стадии MVP вы создадите нечто подобное.

Главное преимущество — скорость запуска. Можно быстро стартовать, не беспокоясь о фронтенде и бэкенде, сразу делать интеграции и не переживать, что что-то не заработает. Такие проблемы возможны, но вероятность их возникновения ниже.

🚀 Развитие и первые ограничения Проект запущен и работает. Интеграции сделаны и проверены, данные перемещаются без сбоев. Что дальше?

Следующий шаг — кастомизация проекта, улучшение отдельных компонентов вроде поиска, фильтров и т.п.

Но развитие приносит новые вызовы. Готовое решение содержит много избыточного кода, и серьезная кастомизация либо невозможна, либо больно. Даже без кастомизации такие универсальные комбайны плохо справляются с возрастающей нагрузкой из-за обилия функциональности.

🔥 Модернизация фронтенда Что делать? Бэкенд менять не хотим, админка и её возможности нас устраивают, тем более что с этой стороны проблем обычно немного. А вот фронтенд хочется сделать современнее, с анимацией, да ещё и мобильное приложение добавить.

Решение: разрабатываем API. На базе текущего бэкенда создаём API для Битрикса, мы обычно используем микрофреймворк Slim. Параллельно разрабатываем отдельный фронтенд — веб, мобильное приложение или что угодно другое. Связываем всё, и вуаля — у нас свой фронтенд, который можно развивать отдельной командой и который лучше справляется с нагрузкой.

⚙️ Модернизация бэкенда Теперь с фронтендом всё решено, у нас устойчивое решение, которое можно развивать долгое время большой командой. Но возникает следующая проблема: бэкенд уже обрабатывает тысячи заказов, и инфраструктура Битрикс не справляется.

Следующий шаг — разделение на отдельные сервисы. Обычно начинают с каталога, который включает в себя поиск, фильтрацию, выдачу и т.д. Появится PIM-система и/ или Elasticsearch. Шина данных, которая разгрузит обмены с внешними системами.

В результате получается своего рода "Франкенштейн": фронтенд — отдельное приложение, API работает через Битрикс, а к нему подключена куча сервисов.

🧠 Полная модернизация Следующим шагом развития становится полная замена бэкенда. Вероятно, выбор падёт на фреймворк типа Laravel или что-то похожее. В итоге мы получаем полноценную микросервисную структуру с отдельным фронтендом и бэкендом.

🛡 Заключение Этот эволюционный путь, конечно, сопряжён с множеством сложностей. Как минимум, придётся делать несколько крупных миграций и решать сопутствующие проблемы. Однако такой подход защищает от колоссальных рисков неверно спланированной долгосрочной разработки.

Описанный путь применим как для B2B, так и для B2C, и для любого коробочного решения — Битрикс использован лишь в качестве примера. Вы можете взять любую другую CMS и повторить этот подход.

Конечно, данный путь не всегда оптимален. Если система пересобирается с нуля, например, при переработке устаревшего проекта, то, вероятно, рациональнее сразу использовать современный фреймворк и архитектуру.