Magento 2 как безголовое решение

48

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

Типичная электронная коммерция в 2017 году - иметь многоканальное решение, которое включает

  • Электронная коммерция
  • CMS
  • Multiplatform
  • Интеграция системы уровня (ERP, ...)

Я хочу знать, как задействовать Magento 2 API с таким решением.

Мой подход:

  • Используйте другую среду внешнего интерфейса (например, угловую) для настольного / мобильного веб-приложения и мобильного приложения

  • Используйте Magento 2 API только для извлечения или взаимодействия с данными / действиями в области электронной коммерции.

  • Используйте CMS API только для извлечения данных CMS.

Pro: только API, все каналы

Минусы: ограничение по производительности / функциям / форматированию

Некоторые вопросы для этого подхода:

  • Кто отвечает за форматирование данных, например, цены. Magento API и интерфейс веб-интерфейса?
  • Кто отвечает за изменение размеров изображений продуктов и их кэширование? Потому что в нативном Magento 2 API нет системы изменения размера или кеша.
  • Нужно ли создавать новый пользовательский изолированный API или расширять собственный для будущих целей обновления?
  • Вы рекомендуете использовать дополнительный слой для объединения CMS и Magento API?

Я ценю, что вы поделились своим опытом.

Более того, я нашел такой подход: http://fbrnc.net/blog/2015/10/super-scaling-magento

Полезные ссылки:

РЕДАКТИРОВАТЬ :

Я нашел хороший загрузчик для создания собственной логики кеша для вашего Magento 2 API: https://github.com/magespecialist/m2-MSP_APIEnhancer

РЕДАКТИРОВАТЬ: хороший проект с открытым исходным кодом для использования Magento 2 в качестве безголовой электронной коммерции с VueJS PWA: https://github.com/DivanteLtd/vue-storefront

РЕДАКТИРОВАТЬ: Официальные инструменты PWA Magento 2 на основе React: https://github.com/magento-research/pwa-studio

magento2 api best-practice Франк Гарнье
источник
: / Не уверен, что мне нравится этот "безголовый" причуды, я имею в виду умные разработчики делали это в течение многих лет, когда это необходимо, вы создаете интерфейс и просто используете запросы к базе данных для манипулирования данными, с кэшированием запросов, структурами данных memcaching и полной страницей кэширование по мере необходимости.
Вулф
Да, но вам нужен интерфейс, такой как Magento 2 API.
Франк Гарнье
Не совсем, все интерфейсы CRUD являются просто дополнительными ненужными слоями для запросов SQL, для интерфейсов, которые делают больше, вы можете часто загружать и просто вызывать собственные функции / методы, чтобы делать то, что нужно. Все, что я говорю, это просто новое имя для чего-то, что давно существует. Мы, вероятно, не придем к консенсусу, и это, вероятно, не место для этого, так что удачи в вашем проекте.
Вулф
Я никогда не говорил, что этот подход новый. Но даже если вы можете сделать это без уровня API Magento с прямым запросом, вы потеряете все преимущества обслуживания. Например, абстракция базы данных, обратная совместимость и так далее. Вы можете избежать использования Magento API, но вам нужно добавить свой собственный слой. Благодарю.
Франк Гарнье

Ответы:

38

Ответы на вопросы

Кто отвечает за форматирование данных, например, цены. Magento API и интерфейс веб-интерфейса?

Magento API обеспечивает доступ к данным и бизнес-логике . Форматирование данных / цен является частью логики представления , поэтому в этом случае у вас будет больше гибкости для представления информации так, как вы хотите (без необходимости делать это по-мадженто).

Например, вы можете использовать JavaScript для определения настроек локали и предоставления соответствующих данных. Проверьте следующее: navigator.language toLocaleString ()

Или же вы можете даже импортировать цены из Magento в стороннюю систему или в инструмент анализа данных, а форматирование цен в соответствии с форматом валюты только нарушит процесс импорта, пока вы не решите «конвертацию валюты».

Кто отвечает за изменение размеров изображений продуктов и их кэширование? Потому что в нативном Magento 2 API нет системы изменения размера или кеша.

Именно так. Как я уже говорил выше, Magento обеспечивает доступ к данным (без логики представления). Это зависит от вас, как вы будете его использовать.

Например, вы можете выбрать адаптивное изменение размера изображения http://adaptive-images.com/details.htm , чтобы вы могли легко использовать исходное изображение и делать все, что захотите.

Вы можете выбрать способ кэширования изображений, использовать сжатие с потерями или без потерь для уменьшения изображений и т. Д.

Нужно ли создавать новый пользовательский изолированный API или расширять собственный для будущих целей обновления?

Я рекомендую вам сделать свой API, который будет использоваться для логики представления, и вы будете на 99,9% (я думаю) уверены, что на вас не повлияет будущее обновление Magento2 API.

Вы рекомендуете использовать дополнительный слой для объединения CMS и Magento API?

Настоятельно рекомендуется. Но дополнительный слой не должен быть дополнительным приложением; это также может быть модуль Magento2. Хорошая вещь в этом заключается в том, что вы можете комбинировать это так, как хотите; Вы можете создать свой прокси-слой, используя любой язык / технологию, какую захотите.

Я ценю, что вы поделились своим опытом.

Есть много подходов, которые вы можете использовать здесь. Я поделюсь своим мнением по этому поводу.

Мой подход к безголовым

Во- первых, я хотел бы разделить его на два слоя: прокси - слой и слой представления .

Прокси слой

Первое, что вы должны рассмотреть, это создать прокси-слой. За кулисами вы можете использовать Magento API, CMS API, ERP API, x API, что угодно ...

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

Уровень прокси не должен быть закодирован в PHP; он может быть закодирован в Java, NodeJS, или вы даже можете использовать AWS API Gateway, AWS SQS и Lambda для предоставления целого уровня прокси или только его части.

Один из подходов, которые вы можете использовать, описан Фабрицио Бранкой по адресу http://fbrnc.net/blog/2015/10/super-scaling-magento.

Уровень представления

Уровень представления зависит от клиентской платформы; если вы собираетесь использовать его для мобильных приложений, то все ясно, как использовать прокси-API.

Для веб-приложения есть много возможностей. Вы можете использовать:

  • Стандартное PHP-решение (работает на любом фреймворке), где вы можете использовать любой из шаблонизаторов PHP (например, Smarty, Twig, Dwoo ...) для вывода HTML
  • Java / NodeJS / любой язык, с которым вы знакомы
  • Решение, основанное исключительно на JavaScript, которое будет отображать весь HTML и вызывать соответствующие API через ajax, чтобы заполнить его данными
  • Любой гибрид / комбинация этих подходов сверху

Это не по списку книг , я просто поделился несколькими комбинациями. На самом деле, ваше воображение является единственным пределом.

Последние мысли

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

НО, проблема с чисто javascript-решением - это SEO. Если все ваши данные загружаются через Ajax, Google, вероятно, не сможет их проанализировать.

Решение заключается в создании гибридного приложения, которое будет обслуживать всю HTML-страницу при первой загрузке, например, когда вы нажимаете / catalog / shoes. Для дальнейшей навигации по сайту вы можете использовать ajax для выборки только необходимых блоков.

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

Синиса Неделькович
источник
Недостаток использования только нативного API Magento 2 заключается в потере полезной встроенной функции для уровня представления с дублированием кода. Для моего текущего проекта я использовал пользовательские API Magento 2 на основе нативного со слоем кэширования и форматирования. Поэтому я думаю, что частично следую вашему подходу.
Франк Гарнье
Все зависит от варианта использования. С точки зрения времени выхода на рынок, вероятно, быстрее просто интегрировать стороннюю CMS и использовать какое-то облако интеграции для других сервисов, таких как Boomi ( boomi.com ).
Синиса Неделькович
1
Кроме того, даже Lizards и Pumpkins можно рассматривать как хороший пример уровня прокси, хотя я не уверен, использует ли он Rest API по умолчанию (но его можно легко расширить).
Синиса Неделькович
10

Я могу поделиться некоторыми взглядами на разработку безголовых проектов magento, так как моя компания создала 2 из них.

Мы решили использовать responsejs в качестве приложения внешнего интерфейса и связать его с серверным бэкэндом. API-вызовы к magento выполнялись узлом на стороне сервера. Это означало, что звонки в magento не отправлялись из браузера.

С точки зрения API это хорошо, но есть некоторые проблемы, с которыми мы столкнулись во время разработки. Конечные точки Magento2 иногда очень ограничены. По умолчанию обработчик конечных точек не позволяет вводить дополнительные данные в ответ, поскольку они не предоставляются extension_attributesкаждому. С интерфейсом, написанным отдельно, это не очень хорошая новость. Мы много раз сталкивались с необходимостью добавить некоторые данные и не могли сделать это для конечной точки родного magento из-за отсутствия extension_attributes. Эти экземпляры необходимы для того, чтобы либо переопределить конечную точку magento и предоставить нашему собственному интерфейсу дополнительные поля, либо создать нашу собственную конечную точку, расширяющую magento и изменяющую то, что нам нужно.

Например, нам нужно было переопределить, так /rest/V1/categoriesкак magento по умолчанию не добавляет URL-путь в дерево категорий. /rest/V1/productsкоторый должен был получать данные о продукте, был слишком ограничен для нас, так как нам нужно было использовать его для просмотра категорий, и мы хотели получить доступные фильтры в этом ответе.

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

Самой хитрой частью была проверка. Хотя он подготовлен для безголового режима, все же есть некоторые детали, которые требуют специальной настройки. Если вы используете PayPal, то обычно вы будете перенаправлены на сайт PayPal для оплаты с некоторым токеном. Для нас этот токен нужно получить отдельно, так как мы не следуем стандартному пути перенаправления. Аналогичный случай был с подключением Adyen, который требовал перенаправления после размещения заказа. Стандартная конечная точка magento возвращает идентификатор заказа только в случае успеха и не позволяет вводить URL перенаправления. У нас также были некоторые проблемы с реализацией 3dSecure.

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

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

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

Если вы хотите проверить, как он ведет себя, здесь есть ссылки на проекты:

https://therake.com/

https://www.emperia.ch/

Если кто-то говорит по-нидерландски, можете также проверить эту статью о therake: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce.

[ОБНОВИТЬ]

Обновление относительно вопроса о порядке оформления заказа. Как я писал оформить заказ было сложно. Платежные шлюзы на уровнях API практически отсутствуют. Например, при обычной оплате большинство платежных шлюзов перенаправляет вас на другой сайт для завершения платежа. Некоторые из этих модулей создают заказы в magento в состоянии ожидания, некоторые (PayPal Express) перенаправляют до создания заказа. Эти перенаправления часто полагаются на вашу сессию, чтобы получить детали обратно после возвращения. Это было проблемой, так как конечная точка API placeOrder возвращает только идентификатор только что созданного заказа, а не информацию о перенаправлении. Поскольку мы также работали не с magento напрямую, а с бэкэндом узла, сеанс необходимо правильно восстановить при возврате из шлюза. Наши текущие проекты имеют интегрированные шлюзы PayPal и Adyen, и это заняло у нас более 150 часов.

Zefiryn
источник
Отличное объяснение, я сталкиваюсь с похожими проблемами. Можете ли вы объяснить более подробную часть оплаты, например, Paypal в безголовом Magento. Можете ли вы поделиться потоком.
Франк Гарнье
5

Вот проект с открытым исходным кодом https://github.com/ishakhsuvarov/going-headless

Этот репозиторий создается для обсуждения «Going Headless», который был частью сеансов Imagine 2017 DevExchange, для сбора и обсуждения идей, касающихся использования веб-API Magento с пользовательским интерфейсом. Основная цель этого проекта - собрать наиболее критические и болезненные моменты в потоках Web API и разработать решение, которое удовлетворяло бы большинству вариантов использования.

FireBear
источник