Ответы на вопросы
Кто отвечает за форматирование данных, например, цены. 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 . Есть также несколько платных решений для этого, таких как: