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

Типичная система электронной коммерции корпоративного уровня часто представляет собой очень сложный монолит. Он состоит из множества различных подсистем, включая ядро, коммерцию, персонализацию и т. д. Все они должны интегрироваться с другими сторонними службами, такими как ваша CMS, программа лояльности, платежный шлюз и маркетинговые инструменты. Результат может быть дорогим, сложным и трудно масштабируемым. Даже кажущиеся незначительными внешние изменения (например, изменение шрифта) могут потребовать развертывания обновления для всей системы. Оптимизация производительности становится важной проблемой, особенно в электронной коммерции, где сервер отвечает за обработку многочисленных запросов каждый раз, когда пользователь выполняет действие, такое как добавление товаров в корзину, обновление количества и выполнение поиска.

Но что, если есть способ оторваться от традиции?

Способ упростить и ускорить для команд разработчиков создание лучшего пользовательского интерфейса в целом? Именно это и делают дальновидные ритейлеры, применяя более сервисно-ориентированный подход к архитектуре даже самых сложных сайтов электронной коммерции. Изолируя определенный набор функций и отделяя серверные компоненты от пользовательского интерфейса, опытные компании могут устранить необходимость в сложной кодовой базе, которая когда-то требовалась для поддержки различных сервисов. Отсюда развертывание новых функций становится проще, менее пугающим и более экономичным. Изменения могут быть внесены во внешний интерфейс полностью независимо от внутреннего интерфейса. При правильной архитектуре единая серверная система (например, SAP Hybris) может передавать данные во множество различных точек взаимодействия (включая Интернет, мобильные устройства, киоски в магазинах, смарт-телевизоры и т. д.), обеспечивая единообразие взаимодействия с пользователем по всем каналам.

Звучит здорово, но как мы туда попадем?

Изоморфный подход, который отображает один и тот же код как на стороне клиента, так и на стороне сервера, в сочетании с веб-службами RESTful или микрослужбами, открывает все возможности в электронной коммерции.

Посмотрите этот пост Азата Мардана на Isomophic JavaScript:



Почему все говорят об изоморфном/универсальном JavaScript и почему это важно
Первоначально применявшийся к математике, термин «изоморфный был впервые популяризирован в отношении разработки Javascript…medium.com»



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

Один из самых больших приростов производительности связан с тем, что данные могут загружаться асинхронно, что означает, что пользователь может выполнять другие действия во время загрузки данных, не дожидаясь обновления содержимого страницы. Например, пользователь может добавить несколько товаров в свою корзину, не дожидаясь завершения обработки первого действия, в отличие от типичного сценария, когда обращения к серверу означают, что страница должна обновляться при каждом предпринятом действии (что приводит к раздражающему пользовательскому опыту). ). При работе с сайтом электронной коммерции даже дополнительное время загрузки на 100 мс может сильно повлиять на коэффициент конверсии. Есть много примеров, когда бренды выводят изоморфный дизайн на новый уровень. Взгляните на то, как Netflix Technology Blog использует React для развития своего пользовательского интерфейса, чтобы повысить производительность, скорость запуска и модульность. AirbnbEng также были первыми пользователями и написали о своем подходе.

Отрисовывая код на стороне клиента, сервер может оставаться без состояния — состояние сохраняется только в браузере. В отличие от приложения с отслеживанием состояния (большинство существующих веб-приложений), которое записывает информацию об изменениях состояния на сервере во время каждого запроса, приложения без сохранения состояния не сохраняют в памяти никакого состояния (включая информацию, связанную с пользовательскими настройками или действиями, предпринятыми в сессия). Вместо этого на клиента возлагается ответственность за поддержание состояния, сводя к минимуму объем данных, которые необходимо передать. Особенно в электронной коммерции приложения без сохранения состояния более масштабируемы, переносимы и лучше интегрируются с другими облачными сервисами. С приложением без сохранения состояния вы застрахованы, если какой-либо отдельный сервер приложений выйдет из строя или возникнут какие-либо другие проблемы с вашей инфраструктурой (очевидно, проблема для розничных продавцов, поскольку Cyber ​​Week быстро приближается). На пользователя это не повлияет, потому что состояние сохраняется только в его или ее браузере, в отличие от приложения с отслеживанием состояния, где, когда это происходит, его состояние может быть потеряно. В целом, stateless предлагает лучший пользовательский опыт и может быть легко масштабирован по горизонтали.

Как влияет многоканальность?

Рост количества мобильных покупок означает, что розничные продавцы электронной коммерции должны предлагать лучший в своем классе многоканальный опыт при каждом взаимодействии, а бренды, которые инвестируют в мобильный опыт, будут пожинать плоды. Фактически, в настоящее время на мобильные устройства приходится около 30% всех продаж электронной коммерции в США, и они растут в три раза быстрее, чем общий объем продаж электронной коммерции в США. Добавьте к этому, что мобильный опыт обычно сильно отличается от настольного. Например, мобильная версия сайта электронной коммерции обычно предлагает уменьшенную версию, чтобы избежать открытия большого количества подключений, используя такие ресурсы, как данные и время автономной работы. Традиционно мобильные приложения используют универсальные серверные API-интерфейсы, предназначенные для обслуживания ряда различных клиентских интерфейсов. Это может быть разочаровывающим и ограничивающим способом работы с многоканальным взаимодействием.

Front-end, back-end и микросервисы, о боже!

По мере того, как экосистема микросервисов развивается и продолжает усложняться, становится все сложнее разрабатывать интерфейсы, согласованные по всем каналам, особенно когда могут быть задействованы сотни микросервисов. Использование шаблона Backend for Front-end (BFF), при котором вы поддерживаете один backend для каждого взаимодействия с пользователем (т. е. для мобильных устройств или настольных компьютеров), является более масштабируемым и чистым решением. Вот как SoundCloud добился успеха, используя подход BFF, чтобы уйти от монолита.

Примените это на практике.

@WalmartLabs разработала Electrode, платформу для создания универсальных приложений React/Node.js. Электрод следует лучшим отраслевым практикам со стандартизированной структурой и современными технологиями. Определенно стоит проверить.

Что это означает для будущего электронной коммерции?

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

Это сообщение первоначально появилось на www.thinkwrap.com.