Magento 2 comme solution sans tête

Je souhaite savoir s’il existe certaines pratiques recommandées pour utiliser Magento 2 en tant que solution de commerce électronique sans tête .

Un commerce électronique typique en 2017 consiste à avoir une solution omnicanal qui comprend

• Commerce électronique
• CMS
• Multi plateforme
• Intégration système à plusieurs niveaux (ERP, ...)

Je veux savoir comment impliquer l'API Magento 2 avec ce type de solution.

Mon approche:

• Utiliser un cadre frontal différent (tel que angular) pour les applications Web et mobiles pour ordinateurs de bureau / mobiles

• Utiliser uniquement l'API Magento 2 afin de récupérer ou d'interagir avec des données / actions de commerce électronique

• Utilisez uniquement l'API CMS pour récupérer les données du CMS.

Pro: uniquement les API, omnicanal

Inconvénients: limitation des performances / fonctionnalités / formatage

Quelques questions pour cette approche:

• Qui est responsable du formatage des données, par exemple les prix. API Magento et infrastructure frontale?
• Qui est responsable du redimensionnement des images de produits et de leur mise en cache? Parce que dans l'API native Magento 2, il n'y a pas de système de redimensionnement ou de cache.
• Dois-je créer une nouvelle API isolée personnalisée ou une extension native pour une mise à niveau ultérieure?
• Recommandez-vous d'utiliser une couche supplémentaire afin de combiner CMS et l'API Magento?

Je vous remercie de partager votre retour d'expérience.

De plus, j'ai trouvé cette approche: http://fbrnc.net/blog/2015/10/super-scaling-magento

Liens utiles:

• 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/

MODIFIER :

J'ai trouvé un bon bootstrap pour créer votre propre logique de cache pour votre API Magento 2: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDIT: Un beau projet open source pour utiliser Magento 2 comme un e-commerce sans tête avec VueJS PWA: https://github.com/DivanteLtd/vue-storefront

EDIT: Les outils PWA officiels de Magento 2 basés sur React: https://github.com/magento-research/pwa-studio

Réponses aux questions

Qui est responsable du formatage des données, par exemple les prix. API Magento et infrastructure frontale?

L'API Magento fournit un accès aux données et à la logique métier . Le formatage des données / prix fait partie de la logique de présentation . Ainsi, vous avez plus de flexibilité pour présenter les informations comme vous le souhaitez (sans être obligé de le faire de la manière Magento).

Par exemple, vous pouvez utiliser JavaScript pour détecter les paramètres régionaux et fournir les données appropriées. Vérifiez les éléments suivants: navigator.language toLocaleString ()

Vous pouvez également choisir d'importer les prix de Magento vers un système tiers ou un outil d'analyse des données. De plus, le formatage des prix en fonction du format de la devise interromprait le processus d'importation jusqu'à ce que vous résolviez la "conversion de devise".

Qui est responsable du redimensionnement des images de produits et de leur mise en cache? Parce que dans l'API native Magento 2, il n'y a pas de système de redimensionnement ou de cache.

Exactement. Comme je l'ai dit plus haut, Magento fournit un accès aux données (sans logique de présentation). C'est à vous de choisir comment vous allez l'utiliser.

Par exemple, vous pouvez opter pour le redimensionnement adaptatif des images http://adaptive-images.com/details.htm , afin de pouvoir facilement utiliser l'image originale et faire ce que vous voulez.

Vous pouvez choisir la manière dont vous allez mettre en cache les images, voulez-vous utiliser la compression avec ou sans perte pour réduire les images, etc.

Dois-je créer une nouvelle API isolée personnalisée ou une extension native pour une mise à niveau ultérieure?

Je vous recommande de créer votre API qui sera utilisée pour la logique de présentation et vous serez à 99,9% (à mon avis) certain de ne pas être affecté par une future mise à niveau de l'API Magento2.

Recommandez-vous d'utiliser une couche supplémentaire pour combiner le CMS et l'API Magento?

Hautement recommandé. Mais, la couche supplémentaire ne doit pas nécessairement être une application supplémentaire; cela peut aussi être un module Magento2. La bonne chose à ce sujet est le fait que vous êtes libre de le combiner comme vous le souhaitez. vous pouvez construire votre couche proxy en utilisant le langage / la technologie de votre choix.

Je vous remercie de partager votre retour d'expérience.

Il existe de nombreuses approches que vous pouvez utiliser ici. Je vais partager mon opinion à ce sujet.

Mon approche sans tête

Premièrement, je le scindais en deux couches: la couche proxy et la couche présentation .

Couche de proxy

La première chose à considérer concerne la construction de la couche proxy. En coulisse, vous pouvez utiliser l'API Magento, l'API CMS, l'API ERP, l'API x, tout ce que vous voulez ...

Dans la couche proxy, vous êtes libre d'utiliser et d'organiser les données comme vous le souhaitez. Vous pouvez y implémenter la couche de mise en cache, ainsi que des fonctionnalités supplémentaires pour le formatage des données, le suivi des clients, diverses automatisations, etc. En général, tout ce dont vous avez besoin pour jongler facilement dans la couche de présentation.

La couche proxy n'a pas besoin d'être codée en PHP; il peut être codé en Java, NodeJS, ou vous pouvez même utiliser AWS API Gateway, AWS SQS et Lambda pour fournir une couche de proxy entière ou une partie de celle-ci.

L'une des approches que vous pouvez utiliser est décrite par Fabrizio Branca à l' adresse http://fbrnc.net/blog/2015/10/super-scaling-magento.

Couche de présentation

La couche de présentation dépend de la plate-forme cliente. si vous envisagez de l'utiliser pour une application mobile, la manière dont vous devriez utiliser l'API proxy est assez claire.

Pour une application Web, les possibilités sont nombreuses. Vous pouvez utiliser:

• Solution PHP standard (optimisée par n'importe quel framework) où vous pouvez utiliser n'importe quel moteur de modélisation PHP (comme Smarty, Twig, Dwoo ...) pour générer une sortie HTML
• Java / NodeJS / quelle que soit la langue avec laquelle vous vous sentez familier
• Solution purement basée sur javascript, qui rendrait tout le code HTML et appellerait les API appropriées via ajax pour le remplir avec des données
• Toute combinaison / combinaison de ces approches ci-dessus

Ce n'est pas dans la liste des livres , je viens de partager quelques combinaisons. En réalité, votre imagination est la seule limite.

Dernières pensées

Utilisez autant que possible une solution basée sur JavaScript, car elle peut offrir une meilleure expérience au client, une charge utile plus réduite pour les charges de page, vous pouvez même effectuer une charge de données spéculative si vous pouvez prévoir les actions à venir du client.

MAIS, le problème avec la solution purement javascript est le référencement. Si toutes vos données sont chargées via Ajax, Google ne serait probablement pas en mesure de les analyser.

La solution consiste à créer une application hybride qui servira une page HTML entière lors du premier chargement, par exemple lorsque vous frappez / catalog / shoes. Pour toute navigation ultérieure sur le site, vous pouvez utiliser ajax pour ne récupérer que les blocs nécessaires.

Une des approches serait de créer des instantanés de votre page, par exemple en utilisant PhantomJS . Il existe également peu de solutions payantes pour cela, comme:

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

Je peux partager quelques idées sur le développement de projets magento sans tête puisque ma société en a créé deux.

Nous avons décidé d'utiliser reactjs en tant qu'application frontale et de le connecter avec un backend alimenté par nœud. Les appels d'API à magento ont été effectués par le nœud côté serveur. Cela signifie qu'aucun appel à magento n'a été envoyé depuis le navigateur.

Du point de vue de l’API, c’est bien, mais nous avons rencontré certains problèmes au cours du développement. Les points de terminaison Magento2 sont parfois très limités. Par défaut, le gestionnaire de points de terminaison ne permet pas d'injecter des données supplémentaires dans la réponse car elles ne sont pas fournies extension_attributesà chacune d'entre elles. Avec frontend écrit séparément, ce n'est pas une bonne nouvelle. Nous avons souvent été confrontés à la nécessité d'ajouter des données et ne pouvions pas le faire pour le système d'extrémité natif de magento en raison d'un manque de données extension_attributes. Ces instances doivent soit remplacer le point de terminaison magento et fournir notre propre interface avec des champs supplémentaires, soit créer notre point de terminaison personnalisé étendant celui de magento et modifiant ce dont nous avons besoin.

Par exemple, nous avons dû remplacer /rest/V1/categoriesmagento par défaut, sans ajouter de chemin d’URL à l’arborescence des catégories. /rest/V1/productsle nombre de données de produit à récupérer était également trop limité pour nous car nous devions l’utiliser pour la vue des catégories et nous souhaitions recevoir les filtres disponibles dans cette réponse.

Un autre problème était les points finaux manquants. Nous devions en créer pour envoyer des courriels de contact, des chapitres pour une catégorie, récupérer des données de devis à partir de quoteId et quelques autres pour traiter des éléments spécifiques à un projet. De manière générale, vous devrez peut-être ajouter votre point de terminaison api là où, dans le front normal de Magento2, vous créeriez un bloc récupérant une collection personnalisée.

La partie la plus difficile était la caisse. Bien qu'il soit prêt pour le mode sans tête, il reste encore certaines pièces nécessitant un ajustement spécifique. Si vous utilisez paypal, vous serez normalement redirigé vers le site paypal pour le paiement avec un tokent. Pour nous, ce jeton doit être récupéré séparément car nous ne suivons pas le mode de redirection standard. Un cas similaire concernait le raccordement d'Adyen, qui nécessitait une redirection après la commande. Le point de terminaison standard magento ne renvoie que l’identifiant de l’ordre en cas de succès et ne permet pas d’injecter une URL de redirection. Nous avons également rencontré des problèmes lors de l’implémentation de 3dSecure.

Un élément important à prendre en compte et à clarifier pour le client avant de partir sans tête est que toutes les parties des modules externes liées au client devront être réécrites pour votre implémentation spécifique. Actuellement, il n’ya aucun moyen pour un module d’ajouter ses propres données à une partie sans interface graphique. Le module ne peut que fournir des points de terminaison d'API.

Dans l'ensemble, magento sans tête est certainement possible. Nous avons finalement créé un module personnalisé pour ces ajustements et de nouveaux systèmes d'extrémité pouvant être utilisés avec d'autres projets.

React front fonctionne très bien, car react front peut mettre en cache beaucoup de choses et le nœud principal est extrêmement rapide. Nous supprimons le temps nécessaire pour afficher une partie de la requête standard de magento de cette façon.

Si vous voulez vérifier son comportement, voici des liens vers les projets:

https://therake.com/

https://www.emperia.ch/

Si quelqu'un parle néerlandais, vous pouvez également consulter cet article à propos de therake: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[MISE À JOUR]

Mise à jour concernant la question du flux de paiement. Comme je l'ai écrit, la caisse était délicate. Les passerelles de paiement au niveau des API sont pratiquement inexistantes. Par exemple, lors du paiement normal, la plupart des passerelles de paiement vous redirigent vers un site différent pour terminer le paiement. Certains de ces modules créent des commandes dans magento en attente, certains (paypal express) sont redirigés avant la création de la commande. Ces redirections dépendent souvent de votre session pour obtenir des détails après le retour. C'était un problème, car le point d'extrémité api placeOrder ne renvoie que l'id de la commande nouvellement créée et non l'info d'une redirection. Comme nous avons également touché non pas directement magento mais le nœud final, la session doit être correctement restaurée lors du retour de la passerelle. Nos projets actuels ont des passerelles paypal et Adyen intégrées et cela nous a pris plus de 150h.

Voici le projet open source https://github.com/ishakhsuvarov/going-headless

Ce référentiel est créé par discussion "Going Headless", qui faisait partie des sessions DevExchange d'Imagine 2017, afin de recueillir et de discuter des idées concernant l'utilisation de l'API Web de Magento avec une interface frontale personnalisée. L’objectif principal de ce projet est de collecter les points les plus critiques et les plus pénibles des flux d’API Web et du développement d’une solution répondant à la plupart des cas d’utilisation.