Magento 2 jako rozwiązanie bezgłowe

Chcę wiedzieć, czy istnieją jakieś najlepsze praktyki korzystania z Magento 2 jako bezgłowego rozwiązania handlu elektronicznego .

Typowym e-commerce w 2017 roku jest posiadanie wielokanałowego rozwiązania, które obejmuje

• E-commerce
• CMS
• Wieloplatformowy
• Integracja systemu poziomów (ERP, ...)

Chcę wiedzieć, jak zaangażować API Magento 2 w tego rodzaju rozwiązanie.

Moje podejście:

• Użyj innej frontu interfejsu (np. Kątowego) dla aplikacji webowej / mobilnej na komputery stacjonarne / mobilne

• Używaj Magento 2 API tylko do pobierania danych lub działań związanych z handlem elektronicznym

• Używaj API CMS tylko do pobierania danych CMS.

Pro: tylko API, omnichannel

Minusy: ograniczenie wydajności / funkcji / formatowania

Kilka pytań dotyczących tego podejścia:

• Kto jest odpowiedzialny za formatowanie danych, na przykład cen. Magento API i frameworki?
• Kto jest odpowiedzialny za zmianę rozmiaru zdjęć produktów i buforowanie ich? Ponieważ w natywnym interfejsie API Magento 2 nie ma systemu zmiany rozmiaru ani pamięci podręcznej.
• Czy muszę utworzyć nowy niestandardowy izolowany interfejs API lub rozszerzyć go w celu przyszłej aktualizacji?
• Czy zalecamy użycie dodatkowej warstwy w celu połączenia CMS i Magento API?

Dziękujemy za podzielenie się swoim doświadczeniem.

Ponadto znalazłem to podejście: http://fbrnc.net/blog/2015/10/super-scaling-magento

Przydatne linki:

• 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%20Architektura

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

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

EDYTOWAĆ :

Znalazłem dobry bootstrap, aby stworzyć własną logikę pamięci podręcznej dla interfejsu API Magento 2: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDYCJA: Miły projekt open source, aby użyć Magento 2 jako bezgłowego handlu elektronicznego z VueJS PWA: https://github.com/DivanteLtd/vue-storefront

EDYCJA: Oficjalne narzędzia PWA Magento 2 oparte na React: https://github.com/magento-research/pwa-studio

Odpowiedzi na pytania

Kto jest odpowiedzialny za formatowanie danych, na przykład cen. Magento API i frameworki?

Magento API zapewnia dostęp do danych i logiki biznesowej . Formatowanie danych / cen jest częścią logiki prezentacji , więc w ten sposób masz większą elastyczność w prezentowaniu informacji w pożądany sposób (bez konieczności robienia tego w Magento).

Na przykład możesz użyć javascript do wykrywania ustawień regionalnych i dostarczania odpowiednich danych. Sprawdź następujące elementy: navigator.language toLocaleString ()

Lub możesz nawet zaimportować ceny z Magento do systemu zewnętrznego lub narzędzia do analizy danych, a sformatowanie cen zgodnie z formatem waluty przerwałoby proces importowania tylko do momentu rozwiązania „przeliczenia waluty”.

Kto jest odpowiedzialny za zmianę rozmiaru zdjęć produktów i buforowanie ich? Ponieważ w natywnym interfejsie API Magento 2 nie ma systemu zmiany rozmiaru ani pamięci podręcznej.

Dokładnie. Jak powiedziałem powyżej, Magento zapewnia dostęp do danych (bez logiki prezentacji). Od Ciebie zależy, jak będziesz go używać.

Na przykład możesz wybrać adaptacyjną zmianę rozmiaru obrazu http://adaptive-images.com/details.htm , abyś mógł łatwo użyć oryginalnego obrazu i robić, co chcesz.

Możesz wybrać sposób buforowania obrazów, chcesz zastosować kompresję stratną lub bezstratną w celu zmniejszenia obrazów itp.

Czy muszę utworzyć nowy niestandardowy izolowany interfejs API lub rozszerzyć go w celu przyszłej aktualizacji?

Polecam, abyś stworzył interfejs API, który będzie używany do logiki prezentacji, a będziesz miał 99,9% (przypuszczam), że nie będzie to miało wpływu na przyszłe uaktualnienie interfejsu API Magento2.

Czy zalecamy użycie dodatkowej warstwy do połączenia CMS i Magento API?

Wysoce rekomendowane. Ale dodatkowa warstwa nie musi być dodatkową aplikacją; może to być również moduł Magento2. Dobrą rzeczą jest to, że możesz dowolnie łączyć to, co chcesz; możesz zbudować swoją warstwę proxy za pomocą dowolnego języka / technologii, którą chcesz.

Dziękujemy za podzielenie się swoim doświadczeniem.

Można tu zastosować wiele metod. Podzielę się swoją opinią na ten temat.

Moje podejście do Bezgłowego

Najpierw podzieliłbym go na dwie warstwy: warstwę proxy i warstwę prezentacji .

Warstwa proxy

Pierwszą rzeczą, którą musisz wziąć pod uwagę, jest zbudowanie warstwy proxy. Za kulisami możesz używać Magento API, CMS API, ERP API, x API, cokolwiek chcesz ...

W warstwie proxy możesz dowolnie wykorzystywać i porządkować dane tak, jak chcesz. Możesz zaimplementować tam warstwę buforowania, a także dodatkowe funkcje formatowania danych, śledzenia klientów, różnych automatyzacji itp. Ogólnie wszystko, czego potrzebujesz do łatwego żonglowania w warstwie prezentacji.

Warstwa proxy nie musi być kodowana w PHP; można go zakodować w Javie, NodeJS, a nawet użyć AWS API Gateway, AWS SQS i Lambda do zapewnienia całej warstwy proxy lub tylko jej części.

Jedno z podejść, które możesz zastosować, opisano przez Fabrizio Branca na stronie http://fbrnc.net/blog/2015/10/super-scaling-magento

Warstwa prezentacji

Warstwa prezentacji zależy od platformy klienta; jeśli zamierzasz używać go do aplikacji mobilnej, jest całkiem jasne, w jaki sposób powinieneś korzystać z proxy API.

W przypadku aplikacji internetowej istnieje wiele możliwości. Możesz użyć:

• Standardowe rozwiązanie PHP (oparte na dowolnym frameworku), w którym można wykorzystać dowolny z silników szablonów PHP (takich jak Smarty, Twig, Dwoo ...), aby uzyskać wyjście HTML
• Java / NodeJS / w jakimkolwiek języku, który znasz
• Rozwiązanie oparte wyłącznie na javascript, które renderuje cały HTML i wywołuje odpowiednie interfejsy API poprzez ajax, aby zapełnić je danymi
• Każda hybryda / połączenie tych podejść z góry

To nie jest lista książek , udostępniłem kilka kombinacji. W rzeczywistości twoja wyobraźnia jest jedynym ograniczeniem.

Końcowe przemyślenia

Używaj jak najlepiej rozwiązania opartego na javascript, ponieważ może ono zapewnić lepszą obsługę klienta, mniejszy ładunek przy ładowaniu stron, możesz nawet spekulacyjnie ładować dane, jeśli możesz przewidzieć kolejne działania klienta.

ALE problemem z rozwiązaniem czysto javascript jest SEO. Jeśli wszystkie dane zostaną załadowane przez Ajax, Google prawdopodobnie nie będzie w stanie ich przeanalizować.

Rozwiązaniem jest stworzenie aplikacji hybrydowej, która będzie obsługiwać całą stronę HTML przy pierwszym ładowaniu, na przykład po naciśnięciu / katalog / buty. W celu dalszej nawigacji po witrynie możesz użyć ajax, aby pobrać tylko potrzebne bloki.

Jednym z podejść byłoby tworzenie migawek strony, na przykład za pomocą PhantomJS . Istnieje również kilka płatnych rozwiązań, takich jak:

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

Mogę podzielić się spostrzeżeniami na temat rozwijania bezgłowych projektów magento, ponieważ moja firma stworzyła 2 z nich.

Zdecydowaliśmy się użyć Reagjs jako aplikacji frontendowej i połączyć go z backendem opartym na węzłach. Wywołania API do magento zostały wykonane przez węzeł po stronie serwera. Oznaczało to, że żadne wywołania do magento nie były wysyłane z przeglądarki.

Z punktu widzenia API jest to dobre, ale są pewne problemy, które napotkaliśmy podczas tworzenia. Punkty końcowe Magento2 są czasami bardzo ograniczone. Domyślnie procedura obsługi punktu końcowego nie pozwala na wstrzyknięcie dodatkowych danych do odpowiedzi, ponieważ nie są one przekazywane extension_attributeskażdemu z nich. Z frontendem napisanym osobno nie jest to dobra wiadomość. Wiele razy mieliśmy do czynienia z potrzebą dodania niektórych danych i nie mogliśmy tego zrobić dla natywnego punktu końcowego magento z powodu braku extension_attributes. Te przypadki są wymagane, aby albo zastąpić punkt końcowy magento i zapewnić naszemu interfejsowi dodatkowe pola, albo utworzyć nasz niestandardowy punkt końcowy, rozszerzając magento i zmieniając to, czego potrzebujemy.

Na przykład musieliśmy przesłonić, /rest/V1/categoriesponieważ magento domyślnie nie dodawało ścieżki adresu URL do drzewa kategorii. /rest/V1/productsktóre powinny pobierać dane produktu, było również dla nas zbyt ograniczone, ponieważ musieliśmy je wykorzystać w widoku kategorii i chcieliśmy otrzymać dostępne filtry w tej odpowiedzi.

Kolejnym problemem były brakujące punkty końcowe. Musieliśmy stworzyć te do wysyłania kontaktowego adresu e-mail, okruszków dla kategorii, pobierania danych wyceny z quoteId i kilku dodatkowych, aby poradzić sobie z elementami specyficznymi dla projektu. Ogólnie rzecz biorąc, gdzie w normalnym froncie Magento2 utworzyłbyś blok pobierający niestandardową kolekcję, aby poradzić sobie z tym, może być konieczne dodanie punktu końcowego interfejsu API.

Najtrudniejszą częścią była kasa. Chociaż jest przygotowany do trybu bezgłowego, wciąż istnieją pewne elementy, które wymagały specyficznej regulacji. Jeśli korzystasz z systemu PayPal, zwykle zostaniesz przekierowany na stronę PayPal w celu dokonania płatności za pomocą tokena. Dla nas ten token należy pobrać osobno, ponieważ nie przestrzegamy standardowego sposobu przekierowywania. Podobnie było z podłączeniem Adyen, która wymagała przekierowania po złożeniu zamówienia. Standardowy punkt końcowy magento zwraca identyfikator zamówienia tylko w przypadku powodzenia i nie pozwala wstrzykiwać adresu URL przekierowania. Mieliśmy również pewne problemy z implementacją 3dSecure.

Jedną z głównych rzeczy do rozważenia i wyjaśnienia klientowi przed pójściem bezgłowym jest to, że wszystkie części modułów zewnętrznych związane z interfejsem będą musiały zostać przepisane na potrzeby konkretnej implementacji. Ponieważ obecnie nie ma możliwości, aby moduł dodał własne dane do dowolnej części bezgłowej. Jedyne, co moduł może zrobić, to zapewnić punkty końcowe interfejsu API.

Podsumowując, bezgłowe magento jest zdecydowanie możliwe. Skończyło się na niestandardowym module dla tych dostosowań i nowych punktów końcowych, które mogłyby być używane z innymi projektami.

React front działa bardzo dobrze, ponieważ front reagowania może buforować wiele rzeczy, a backend węzła jest niezwykle szybki. W ten sposób usuwamy czas potrzebny na wyświetlenie części standardowego żądania Magento.

Jeśli chcesz sprawdzić, jak się tutaj zachowuje, są linki do projektów:

https://therake.com/

https://www.emperia.ch/

Jeśli ktoś mówi po holendersku, może również sprawdzić ten artykuł o therake: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[AKTUALIZACJA]

Aktualizacja dotycząca pytania o przebieg kasy. Jak pisałem, realizacja transakcji była trudna. Bramki płatnicze na poziomach interfejsu API w zasadzie nie istnieją. Na przykład podczas regularnej realizacji transakcji większość bramek płatności przekierowuje do innej witryny w celu dokończenia płatności. Niektóre z tych modułów tworzą zamówienia w Magento w stanie oczekiwania, niektóre (paypal express) przekierowują przed utworzeniem zamówienia. Te przekierowania często polegają na Twojej sesji, aby odzyskać szczegóły po powrocie. Był to problem, ponieważ punkt końcowy interfejsu API PlaceOrder zwraca tylko identyfikator nowo utworzonego zamówienia, a nie informację o przekierowaniu. Ponieważ również nie uderzaliśmy bezpośrednio w Magento, ale backend węzła, sesja musi zostać poprawnie przywrócona po powrocie z bramy. Nasze obecne projekty mają zintegrowane bramki paypal i Adyen, co zajęło nam ponad 150 godzin.

Oto projekt open source https://github.com/ishakhsuvarov/going-headless

To repozytorium jest tworzone na podstawie dyskusji „Going Headless”, która była częścią sesji Imagine 2017 DevExchange, w celu gromadzenia i omawiania pomysłów dotyczących korzystania z interfejsu API sieci Web Magento z niestandardowym interfejsem użytkownika. Głównym celem tego projektu jest zebranie najbardziej krytycznych i bolesnych punktów w przepływach interfejsu API sieci Web oraz opracowanie rozwiązania, które zaspokoi większość przypadków użycia.