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

Хочу знати, чи є кілька найкращих практик використання Magento 2 як безготівкового електронного комерційного рішення .

Типовою електронною комерцією в 2017 році є створення всеканального рішення, яке включає

• Електронна комерція
• CMS
• Мультиплатформна
• Інтеграція рівня рівнів (ERP, ...)

Хочу знати, як залучити API Magento 2 до подібного рішення.

Мій підхід:

• Використовуйте інший фронтальний фреймворк (наприклад, кутовий) для настільних / мобільних веб-програм і мобільних додатків

• Використовуйте API Magento 2 лише для отримання або взаємодії з електронними комерційними даними / діями

• Використовуйте CMS API лише для отримання даних CMS.

Pro: Тільки API, омніканал

Мінуси: Обмеження щодо продуктивності / особливостей / форматування

Деякі питання для цього підходу:

• Хто несе відповідальність за форматування даних, наприклад ціни. API Magento та фронтенд?
• Хто несе відповідальність за зміну розмірів зображень продуктів та їх кешування? Оскільки в рідному API Magento 2 немає системи зміни розміру чи кешу.
• Чи потрібно мені створити новий індивідуальний ізольований API або розширити нативну для подальшого оновлення?
• Чи рекомендуєте ви використовувати додатковий шар для комбінування API CMS та Magento?

Дякую вам, щоб поділитися своїм досвідом.

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

Корисні посилання:

• https://blogi.lamia.fi/verkkokaupat/headless-ecommerce/
• http://www.magetitans.it/headless-new-buzzword-magento-2-sander-mangel/
• https://www.youtube.com/watch?v=6OuzAtqtWRE

• https://pantheon.io/blog/headless-websites-whats-big-deal-decoupled-architecture

• http://buytaert.net/the-future-of-decoupled-drupal

• https://creately.com/diagram/example-v2/ihbyjjkf/Example%20Headless%20Architecture

• https://www.lullabot.com/articles/should-you-decouple

• https://alankent.me/2016/12/14/headless-magento-and-extensions/

Редагувати:

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

EDIT: Приємний проект з відкритим кодом, щоб використовувати Magento 2 як безголовку електронну комерцію з VueJS PWA: https://github.com/DivanteLtd/vue-storefront

EDIT: Офіційні інструменти Magento 2 PWA на основі React: https://github.com/magento-research/pwa-studio

Відповіді на запитання

Хто несе відповідальність за форматування даних, наприклад ціни. API Magento та фронтенд?

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

Наприклад, ви можете використовувати javascript для виявлення налаштувань локалі та надання відповідних даних. Перевірте наступне: navigator.language toLocaleString ()

Або ви навіть можете імпортувати ціни з Magento до сторонньої системи чи інструменту аналізу даних, а форматування цін відповідно до формату валюти лише порушить процес імпорту, поки ви не вирішите "конвертацію валюти".

Хто несе відповідальність за зміну розмірів зображень продуктів та їх кешування? Оскільки в рідному API Magento 2 немає системи зміни розміру чи кешу.

Саме так. Як я вже говорив вище, Magento забезпечує доступ до даних (без логіки презентації). Саме від вас залежить, як ви будете ним користуватися.

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

Ви можете вибрати спосіб кешування зображень, чи бажаєте ви стиснення втрат чи втрат для зменшення зображень тощо.

Чи потрібно мені створити новий індивідуальний ізольований API або розширити нативну для подальшого оновлення?

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

Чи рекомендуєте ви використовувати додатковий шар для комбінування API CMS та Magento?

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

Дякую вам, щоб поділитися своїм досвідом.

Тут ви можете скористатися багатьма підходами. Я поділюсь своєю думкою з цього приводу.

Мій підхід без голови

По-перше, я б розділив його на два шари: проксі-шар та презентаційний шар .

Проксі-шар

Перше, що вам доведеться врахувати, - це створення проксі-шару. За лаштунками ви можете використовувати Magento API, CMS API, ERP API, x API, що завгодно ...

У проксі-шарі ви можете користуватися та впорядковувати дані так, як вам потрібно. Ви можете реалізувати там кешовий шар, а також додаткові функції для форматування даних, відстеження клієнтів, різних автоматизацій тощо. Загалом, все, що потрібно для легкого жонглювання в презентаційному шарі.

Проксі-рівень не повинен кодуватися в PHP; його можна кодувати в Java, NodeJS або навіть можна використовувати шлюз API AWS, AWS SQS і Lambda для надання цілого проксі-шару або просто його частини.

Один із підходів, якими ви можете скористатися, описаний Fabrizio Branca на веб-сайті 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 при першому завантаженні, наприклад, при натисканні / каталогу / взуття. Для подальшої навігації по сайту ви можете використовувати ajax для отримання лише необхідних блоків.

Одним із підходів було б створення знімків вашої сторінки, наприклад, за допомогою PhantomJS . Для цього також є мало платних рішень, наприклад:

• https://prerender.io
• http://www.brombone.com

Я можу поділитися інформацією щодо розробки безголових проектів магенто, оскільки моя компанія створила 2 з них.

Ми вирішили використати reactjs як додаток для інтерфейсу та з'єднати його із сервісом, що працює на вузлах. Виклики API до magento виконувались вузлом на стороні сервера. Це означало, що жоден дзвінок на магент не надсилався з браузера.

З точки зору API це добре, але є деякі проблеми, з якими ми стикалися під час розробки. Кінцеві точки Magento2 іноді дуже обмежені. За замовчуванням обробник кінцевих точок не дозволяє вводити у відповідь додаткові дані, оскільки вони не надаються extension_attributesкожному. З фронтендом, написаним окремо, це не гарна новина. Ми багато разів стикалися з необхідністю додати деякі дані, і не змогли цього зробити для нативного кінцевої точки магенто через відсутність extension_attributes. Ці екземпляри, необхідні для того, щоб або перекрити кінцеву точку магенто, і забезпечити власний інтерфейс додатковими полями, або створити нашу власну кінцеву точку, розширюючи магенто та змінюючи те, що нам потрібно.

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

Ще однією проблемою були відсутні кінцеві точки. Нам довелося створити такі для надсилання електронної пошти для контактів, сухарі для категорії, отримання даних цитат з quoId та кілька додаткових для розгляду конкретних елементів проекту. Взагалі кажучи, там, де на звичайному Magento2 спереду ви створили б блок, який отримує якусь власну колекцію для вирішення, вам може знадобитися додати кінцеву точку api.

Найбільш хитрою частиною була каса. Хоча він готується до безголового режиму, все ж є деякі частини, які потребують конкретного регулювання. Якщо ви використовуєте paypal, то зазвичай ви будете перенаправлені на сайт paypal для оплати деяким токентом. Для нас цей маркер потрібно отримати окремо, оскільки ми не дотримуємось стандартного способу переадресації. Аналогічний випадок був із підключенням Адієна, який вимагав переадресації після розміщення замовлення. Стандартна кінцева точка magento повертає ідентифікатор замовлення лише після успіху та не дозволяє вводити URL переадресації. У нас також були деякі проблеми з реалізацією 3dSecure.

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

Загалом безголовий магент, безумовно, можливий. У нас з'явився спеціальний модуль для тих коригувань та нових кінцевих точок, які можна було б використовувати в інших проектах.

Реактивний фронт працює дуже добре, тому що реагуючи на фронт, можна кешувати багато речей, а загін вузла надзвичайно швидко Таким чином ми знімаємо час, необхідний для перегляду частини стандартного запиту magento.

Якщо ви хочете перевірити, як він поводиться, ось посилання на проекти:

https://therake.com/

https://www.emperia.ch/

Якщо хтось розмовляє голландською мовою, можете також перевірити цю статтю про терапію: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[ОНОВЛЕННЯ]

Оновлення щодо питання про оплату оформлення замовлення. Як я писав, замовлення було складним. Шлюзи платежів на рівні api в основному відсутні. Наприклад, у звичайній касі більшість платіжних шлюзів перенаправляє вас на інший сайт для завершення платежу. Деякі з цих модулів створюють замовлення в магенто в очікуваному стані, деякі (paypal express) роблять переадресацію перед створенням замовлення. Ці переадресації часто покладаються на ваш сеанс, щоб отримати детальну інформацію після повернення. Це була проблема, оскільки кінцева точка api placeOrder повертає лише ідентифікатор новоствореного замовлення, а не інформацію про переадресацію. Оскільки ми також потрапляли не магенто безпосередньо, а вузький сервер, сеанс потрібно належним чином відновити при поверненні з шлюзу. У наших нинішніх проектах інтегровані шлюзи paypal та Adyen, і це зайняло нам понад 150 годин.

Ось проект з відкритим кодом https://github.com/ishakhsuvarov/going-headless

Цей репозиторій створений за дискусією "Без голові", яка була частиною сесій Imagine 2017 DevExchange, щоб збирати та обговорювати ідеї щодо використання веб-API Magento за допомогою спеціального інтерфейсу. Основна мета цього проекту - зібрати найважливіші та найболючіші моменти в потоках Web API та розробка рішення, яке задовольнило б більшість випадків використання.