Magento 2 als kopflose Lösung

48

Ich möchte wissen, ob es einige Best Practices gibt , um Magento 2 als kopflose E-Commerce-Lösung zu verwenden .

Ein typischer E-Commerce im Jahr 2017 ist eine Omni-Channel-Lösung, die Folgendes beinhaltet

  • E-Commerce
  • CMS
  • Multiplattform
  • Tier Systemintegration (ERP, ...)

Ich möchte wissen, wie die Magento 2-API in diese Art von Lösung eingebunden wird.


Mein Ansatz:

  • Verwenden Sie ein anderes Frontend-Framework (z. B. Angular) für Desktop / Mobile-Webapp und Mobile-App

  • Verwenden Sie die Magento 2-API nur zum Abrufen oder Interagieren mit E-Commerce-Daten / -Aktionen

  • Verwenden Sie die CMS-API nur zum Abrufen von CMS-Daten.

Pro: Nur APIs, Omnichannel

Nachteile: Einschränkung für Leistung / Funktionen / Formatierung


Einige Fragen für diesen Ansatz:

  • Wer ist für die Formatierung der Daten verantwortlich, zum Beispiel die Preise. Magento API und Frontend Framework?
  • Wer ist dafür verantwortlich, die Größe der Produktbilder zu ändern und sie zwischenzuspeichern? Denn in der nativen Magento 2-API gibt es kein Größenänderungs- oder Cache-System.
  • Muss ich eine neue benutzerdefinierte isolierte API erstellen oder die native API für zukünftige Upgrades erweitern?
  • Empfehlen Sie die Verwendung einer zusätzlichen Ebene, um CMS und Magento API zu kombinieren?

Ich freue mich, dass Sie uns Ihre Erfahrungen mitteilen.

Außerdem habe ich diesen Ansatz gefunden: http://fbrnc.net/blog/2015/10/super-scaling-magento

Nützliche Links:

EDIT:

Ich habe einen guten Bootstrap gefunden, um eine eigene Cache-Logik für Ihre Magento 2-API zu erstellen: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDIT: Ein schönes Open-Source-Projekt, um Magento 2 als kopflosen E-Commerce mit VueJS PWA zu nutzen: https://github.com/DivanteLtd/vue-storefront

BEARBEITEN: Die offiziellen Magento 2 PWA-Tools basieren auf React: https://github.com/magento-research/pwa-studio

Franck Garnier
quelle
: / Ich bin mir nicht sicher, ob mir diese "kopflose" Modeerscheinung gefällt. Ich meine, clevere Entwickler machen das schon seit Jahren, wenn es nötig ist. Sie erstellen ein Frontend und verwenden einfach Datenbankabfragen, um die Daten zu manipulieren Caching nach Bedarf.
Wolfe
Ja, aber Sie benötigen eine Schnittstelle wie die Magento 2-API.
Franck Garnier
Nicht wirklich, alle CRUD-Schnittstellen sind nur zusätzliche nicht benötigte Ebenen für SQL-Abfragen. Für Schnittstellen, die mehr leisten, können Sie häufig Bootstraps durchführen und nur native Funktions- / Methodenaufrufe ausführen, um das zu tun, was benötigt wird. Ich sage nur, es ist nur ein neuer Name für etwas, das es schon lange gibt. Wir werden wahrscheinlich nicht zu einer Einigung kommen und dies ist wahrscheinlich nicht der richtige Ort dafür, also viel Glück mit Ihrem Projekt.
Wolfe
Ich habe nie gesagt, dass dieser Ansatz neu ist. Aber selbst wenn Sie ohne die Magento-API-Ebene mit direkter Abfrage auskommen, verlieren Sie alle Wartungsvorteile. Wie die Datenbankabstraktion, die Abwärtskompatibilität und so weiter. Sie können die Magento-API umgehen, müssen jedoch eine eigene Ebene hinzufügen. Vielen Dank.
Franck Garnier

Antworten:

38

Antworten auf die Fragen

Wer ist für die Formatierung der Daten verantwortlich, zum Beispiel die Preise. Magento API und Frontend Framework?

Die Magento-API bietet Zugriff auf die Daten und die Geschäftslogik . Die Formatierung von Daten / Preisen ist Teil der Präsentationslogik. Auf diese Weise haben Sie mehr Flexibilität bei der Darstellung von Informationen nach Ihren Wünschen (ohne dazu gezwungen zu sein, dies mit Magento zu tun).

Beispielsweise können Sie Javascript verwenden, um Gebietsschemaeinstellungen zu erkennen und entsprechende Daten bereitzustellen. Überprüfen Sie Folgendes: navigator.language toLocaleString ()

Oder Sie können sogar Preise aus Magento in ein System eines Drittanbieters oder in ein Datenanalysetool importieren. Wenn Sie die Preise gemäß dem Währungsformat formatieren, wird der Importvorgang nur unterbrochen, bis Sie die "Währungsumrechnung" lösen.

Wer ist dafür verantwortlich, die Größe der Produktbilder zu ändern und sie zwischenzuspeichern? Denn in der nativen Magento 2-API gibt es kein Größenänderungs- oder Cache-System.

Genau. Wie bereits erwähnt, bietet Magento Zugriff auf die Daten (ohne Präsentationslogik). Es liegt an Ihnen, wie Sie es verwenden.

Beispielsweise können Sie die Größe des adaptiven Bilds http://adaptive-images.com/details.htm ändern , damit Sie das Originalbild problemlos verwenden und tun können, was Sie möchten.

Sie können wählen, wie Sie Bilder zwischenspeichern, verlustbehaftete oder verlustfreie Komprimierung zum Reduzieren von Bildern verwenden möchten usw.

Muss ich eine neue benutzerdefinierte isolierte API erstellen oder die native API für zukünftige Upgrades erweitern?

Ich empfehle Ihnen, Ihre API so zu gestalten, dass sie für die Präsentationslogik verwendet wird, und Sie sind zu 99,9% sicher, dass Sie von einem zukünftigen Upgrade der Magento2-API nicht betroffen sind.

Empfehlen Sie die Verwendung einer zusätzlichen Ebene, um CMS und Magento API zu kombinieren?

Sehr empfehlenswert. Die zusätzliche Ebene muss jedoch keine zusätzliche Anwendung sein. Es kann auch ein Magento2-Modul sein. Das Gute daran ist, dass Sie es nach Belieben kombinieren können. Sie können Ihre Proxy-Ebene mit jeder gewünschten Sprache / Technologie erstellen.

Ich freue mich, dass Sie uns Ihre Erfahrungen mitteilen.

Es gibt viele Ansätze, die Sie hier verwenden können. Ich werde meine Meinung dazu teilen .

Mein Ansatz zu Headless

Zuerst würde ich es in zwei Ebenen aufteilen: Proxy-Ebene und Präsentations-Ebene .

Proxy-Schicht

Das erste, was Sie berücksichtigen müssen, ist das Erstellen der Proxy-Ebene. Hinter den Kulissen können Sie die Magento-API, die CMS-API, die ERP-API und die x-API nach Belieben verwenden ...

In der Proxy-Ebene können Sie die Daten nach Belieben verwenden und organisieren. Sie können dort die Caching-Ebene sowie zusätzliche Funktionen für die Datenformatierung, Kundenverfolgung, verschiedene Automatisierungen usw. implementieren. Im Allgemeinen alles, was Sie zum einfachen Jonglieren in der Präsentations-Ebene benötigen.

Die Proxy-Ebene muss nicht in PHP codiert sein. Es kann in Java, NodeJS codiert werden oder Sie können sogar AWS API Gateway, AWS SQS und Lambda verwenden, um eine ganze Proxy-Schicht oder nur einen Teil davon bereitzustellen.

Einer der möglichen Ansätze wird von Fabrizio Branca unter http://fbrnc.net/blog/2015/10/super-scaling-magento beschrieben

Präsentationsfolie

Die Darstellungsebene hängt von der Client-Plattform ab. Wenn Sie es für Mobile App verwenden möchten, ist ziemlich klar, wie Sie die Proxy-API verwenden sollten.

Für eine Webanwendung gibt es viele Möglichkeiten. Sie können verwenden:

  • Standard-PHP-Lösung (basierend auf einem beliebigen Framework), bei der Sie eine beliebige PHP-Template-Engine (wie Smarty, Twig, Dwoo ...) verwenden können, um HTML-Ausgabe bereitzustellen
  • Java / NodeJS / welche Sprache Sie auch immer kennen
  • Rein auf Javascript basierende Lösung, die alles HTML rendert und entsprechende APIs über Ajax aufruft, um es mit Daten zu füllen
  • Beliebige Hybrid / Kombination dieser Ansätze von oben

Dies ist nicht von der Buchliste, ich habe nur wenige Kombinationen geteilt. In Wirklichkeit ist Ihre Vorstellungskraft die einzige Grenze.

Abschließende Gedanken

Verwenden Sie so oft wie möglich eine auf Javascript basierende Lösung, da dies dem Kunden eine bessere Erfahrung bieten kann, die Nutzlast für das Laden von Seiten geringer ist und Sie sogar spekulative Daten laden können, wenn Sie die nächsten Aktionen des Kunden vorhersagen können.

ABER das Problem mit der reinen Javascriptlösung ist SEO. Wenn alle Ihre Daten über Ajax geladen werden, kann Google sie wahrscheinlich nicht analysieren.

Die Lösung besteht darin, eine Hybrid-App zu erstellen, die beim ersten Laden die gesamte HTML-Seite bedient, z. B. wenn Sie auf / catalog / shoes klicken. Für jede weitere Navigation durch die Site können Sie Ajax verwenden, um nur die benötigten Blöcke abzurufen.

Einer der Ansätze wäre das Erstellen von Schnappschüssen Ihrer Seite, beispielsweise mit PhantomJS . Es gibt auch einige kostenpflichtige Lösungen dafür, wie zum Beispiel:

Sinisa Nedeljkovic
quelle
Der Nachteil der Verwendung nur der nativen Magento 2-API besteht darin, dass die nützliche integrierte Funktion für die Präsentationsschicht bei der Codeduplizierung verloren geht. Für mein aktuelles Projekt habe ich benutzerdefinierte Magento 2-APIs verwendet, die auf nativen APIs mit Caching- und Formatierungsebene basieren. Ich glaube, ich folge teilweise Ihrem Ansatz.
Franck Garnier
Alles hängt vom Anwendungsfall ab. In Bezug auf die Markteinführungszeit ist es wahrscheinlich schneller, CMS von Drittanbietern zu integrieren und eine Art Integrationswolke für andere Dienste wie Boomi ( boomi.com ) zu verwenden.
Sinisa Nedeljkovic
1
Darüber hinaus können sogar Eidechsen und Kürbisse als gutes Beispiel für die Proxy-Ebene angesehen werden, obwohl ich nicht sicher bin, ob sie standardmäßig die Rest-API verwendet (sie kann jedoch problemlos erweitert werden).
Sinisa Nedeljkovic
10

Ich kann einige Einblicke in die Entwicklung kopfloser Magento-Projekte geben, da meine Firma zwei davon erstellt hat.

Wir haben uns entschlossen, reactjs als Frontend-Anwendung zu verwenden und mit dem Node-Powered-Backend zu verbinden. API-Aufrufe an Magento wurden vom Knoten auf der Serverseite ausgeführt. Dies bedeutete, dass keine Anrufe an Magento vom Browser gesendet wurden.

Aus API-Sicht ist es gut, aber es gibt einige Probleme, die wir während der Entwicklung festgestellt haben. Magento2-Endpunkte sind manchmal sehr begrenzt. Standardmäßig erlaubt der Endpoint Handler nicht, zusätzliche Daten in die Antwort einzufügen, da diese nicht für extension_attributesjede Antwort bereitgestellt werden . Wenn das Frontend separat geschrieben ist, ist es keine gute Nachricht. Wir mussten viele Male Daten hinzufügen und konnten dies für den nativen Magento-Endpunkt mangels nicht tun extension_attributes. Diese Instanzen sind erforderlich, um entweder den Magento-Endpunkt zu überschreiben und unsere eigene Schnittstelle mit zusätzlichen Feldern zu versehen, oder um einen benutzerdefinierten Endpunkt zu erstellen, der den Magento-Endpunkt erweitert und die von uns benötigten Änderungen vornimmt.

Zum Beispiel mussten wir überschreiben, /rest/V1/categoriesda Magento dem Kategoriebaum standardmäßig keinen URL-Pfad hinzufügte. /rest/V1/productsDas Abrufen von Produktdaten war für uns ebenfalls zu begrenzt, da wir es für die Kategorieansicht verwenden mussten und in dieser Antwort verfügbare Filter erhalten wollten.

Ein weiteres Problem waren fehlende Endpunkte. Wir mussten solche erstellen, um Kontakt-E-Mails zu senden, Brotkrumen für die Kategorie zu erstellen, Angebotsdaten von quoteId abzurufen und einige zusätzliche, um projektspezifische Elemente zu behandeln. Im Allgemeinen, wenn Sie in normaler Magento2-Version einen Block erstellen, der eine benutzerdefinierte Sammlung abruft, um damit umzugehen, müssen Sie möglicherweise Ihren API-Endpunkt hinzufügen.

Der schwierigste Teil war das Auschecken. Obwohl es für den Headless-Modus vorbereitet ist, müssen einige Teile noch spezifisch angepasst werden. Wenn Sie Paypal verwenden, werden Sie normalerweise zur Zahlung mit einem Token auf die Paypal-Website weitergeleitet. Für uns muss dieses Token separat abgerufen werden, da wir keine Standardumleitung verwenden. Ein ähnlicher Fall war das Anschließen von Adyen, für das nach der Bestellung eine Umleitung erforderlich war. Der Standard-Magento-Endpunkt gibt nur bei Erfolg die Bestell-ID zurück und lässt keine Weiterleitungs-URL zu. Wir hatten auch Probleme mit der Implementierung von 3dSecure.

Eine wichtige Sache, die Sie berücksichtigen und dem Kunden klar machen müssen, bevor Sie kopflos arbeiten, ist, dass alle Frontend-bezogenen Teile externer Module für Ihre spezifische Implementierung neu geschrieben werden müssen. Derzeit gibt es für ein Modul keine Möglichkeit, einem kopflosen Teil eigene Daten hinzuzufügen. Das Modul kann nur API-Endpunkte bereitstellen.

Alles in allem ist kopfloses Magento definitiv möglich. Am Ende hatten wir ein benutzerdefiniertes Modul für diese Anpassungen und neuen Endpunkte, die für andere Projekte verwendet werden konnten.

React Front funktioniert sehr gut, da React Front viele Dinge zwischenspeichern kann und das Node Backend extrem schnell ist. Auf diese Weise entfällt die Zeit, die zum Anzeigen eines Teils der Standard-Magento-Anforderung erforderlich ist.

Wenn Sie überprüfen möchten, wie es sich verhält, finden Sie hier Links zu den Projekten:

https://therake.com/

https://www.emperia.ch/

Wenn jemand Niederländisch spricht, lesen Sie auch diesen Artikel über das Thema: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[AKTUALISIEREN]

Update bezüglich der Frage zum Checkout-Ablauf. Wie ich schrieb, war das Auschecken schwierig. Zahlungsgateways auf API-Ebenen sind grundsätzlich nicht vorhanden. Zum Beispiel leiten Sie die meisten Zahlungsgateways beim regulären Checkout an die andere Site weiter, um die Zahlung abzuschließen. Einige dieser Module erstellen Bestellungen in Magento in ausstehendem Zustand, andere (Paypal Express) leiten diese um, bevor eine Bestellung erstellt wird. Diese Weiterleitungen hängen häufig von Ihrer Sitzung ab, damit Sie nach der Rücksendung weitere Informationen erhalten. Dies war ein Problem, da der API-Endpunkt placeOrder nur die ID der neu erstellten Bestellung und nicht die Informationen einer Umleitung zurückgibt. Da wir auch nicht direkt auf Magento, sondern auf das Node-Backend zugegriffen haben, muss die Sitzung bei der Rückkehr vom Gateway ordnungsgemäß wiederhergestellt werden. Unsere aktuellen Projekte haben Paypal- und Adyen-Gateways integriert und es dauerte über 150 Stunden.

Zefiryn
quelle
Gute Erklärung, ich stoße auf ähnliche Probleme. Kannst du mir den Zahlungsteil näher erläutern, zum Beispiel Paypal in einem kopflosen Magento. Kannst du den Fluss teilen?
Franck Garnier
5

Hier ist Open-Source-Projekt https://github.com/ishakhsuvarov/going-headless

Dieses Repository wird gemäß der Diskussion "Going Headless" erstellt, die Teil der DevExchange-Sitzungen von Imagine 2017 war, um Ideen zur Verwendung der Magento-Web-API mit benutzerdefiniertem Frontend zu sammeln und zu diskutieren. Das Hauptziel dieses Projekts ist es, die kritischsten und schmerzhaftesten Punkte in den Web-API-Abläufen zu sammeln und eine Lösung zu entwickeln, die die meisten Anwendungsfälle befriedigt.

Feuerbär
quelle