Magento 2 come soluzione senza testa


48

Voglio sapere se ci sono alcune migliori pratiche per utilizzare Magento 2 come soluzione di e-commerce senza testa .

Un tipico e-commerce nel 2017 è avere una soluzione omni-channel che includa

  • E-commerce
  • CMS
  • Multi piattaforma
  • Integrazione del sistema di livello (ERP, ...)

Voglio sapere come coinvolgere Magento 2 API con questo tipo di soluzione.


Il mio approccio:

  • Utilizzare un framework frontend diverso (come ad esempio angolare) per l'app desktop / mobile e l'app mobile

  • Utilizza l'API Magento 2 solo per recuperare o interagire con dati / azioni e-commerce

  • Utilizzare l'API CMS solo per recuperare i dati CMS.

Pro: solo API, omnicanale

Contro: Limitazione per prestazioni / caratteristiche / formattazione


Alcune domande per questo approccio:

  • Chi è responsabile della formattazione dei dati, ad esempio i prezzi. API Magento e framework frontend?
  • Chi è responsabile del ridimensionamento delle immagini dei prodotti e della loro memorizzazione nella cache? Perché nell'API nativa di Magento 2 non esiste un sistema di ridimensionamento o cache.
  • Devo creare una nuova API isolata personalizzata o estendere nativa per scopi di aggiornamento futuro?
  • Consiglieresti di usare un livello aggiuntivo per combinare CMS e Magento API?

Ti apprezzo per condividere il tuo ritorno in esperienza.

Inoltre, ho trovato questo approccio: http://fbrnc.net/blog/2015/10/super-scaling-magento

Link utili:

MODIFICARE :

Ho trovato un buon bootstrap per creare la tua logica cache per la tua API Magento 2: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDIT: un bel progetto open source per utilizzare Magento 2 come e-commerce senza testa con VueJS PWA: https://github.com/DivanteLtd/vue-storefront

EDIT: gli strumenti PWA Magento 2 ufficiali basati su React: https://github.com/magento-research/pwa-studio


: / non sono sicuro che mi piaccia questa moda "senza testa", intendo che gli sviluppatori intelligenti lo fanno da anni quando necessario, fai un frontend e usi le query del database per manipolare i dati, con memorizzazione nella cache delle query, memorizzazione di strutture di dati e pagina intera memorizzazione nella cache, se necessario.
Wolfe,

Sì, ma hai bisogno di un'interfaccia come l'API Magento 2.
Franck Garnier,

Non proprio, tutte le interfacce CRUD sono solo livelli extra non necessari per le query sql, per le interfacce che fanno di più, puoi spesso avviare il bootstrap ed effettuare semplicemente chiamate di funzione / metodo native per fare ciò che è necessario. Tutto quello che sto dicendo è che è solo un nuovo nome per qualcosa che esiste da tempo. Probabilmente non arriveremo al consenso e questo probabilmente non è il posto adatto, quindi buona fortuna con il tuo progetto.
Wolfe,

Non ho mai detto che questo approccio è nuovo. Ma anche se puoi farlo senza il livello API Magento con query diretta, perdi tutti i vantaggi di manutenzione. Come l'astrazione del database, la retrocompatibilità e così via. Puoi evitare l'API Magento, ma devi aggiungere il tuo livello. Grazie.
Franck Garnier,

Risposte:


38

Risposte alle domande

Chi è responsabile della formattazione dei dati, ad esempio i prezzi. API Magento e framework frontend?

L'API Magento fornisce l'accesso ai dati e alla logica aziendale . La formattazione di dati / prezzi fa parte della logica di presentazione , quindi in questo modo hai più flessibilità nel presentare le informazioni nel modo desiderato (senza essere costretto a farlo nel modo Magento).

Ad esempio, è possibile utilizzare JavaScript per rilevare le impostazioni locali e fornire dati appropriati. Controlla quanto segue: navigator.language toLocaleString ()

Oppure, puoi anche scegliere di importare i prezzi da Magento a un sistema di terze parti, o uno strumento di analisi dei dati, e avere i prezzi formattati in base al formato della valuta interromperebbe il processo di importazione solo fino a quando non risolvi la "conversione di valuta".

Chi è responsabile del ridimensionamento delle immagini dei prodotti e della loro memorizzazione nella cache? Perché nell'API nativa di Magento 2 non esiste un sistema di ridimensionamento o cache.

Esattamente. Come ho detto sopra, Magento fornisce l'accesso ai dati (senza logica di presentazione). Dipende da te come lo userai.

Ad esempio, puoi scegliere di ridimensionare l'immagine adattiva http://adaptive-images.com/details.htm , in modo da poter utilizzare facilmente l'immagine originale e fare quello che vuoi.

Puoi scegliere il modo in cui memorizzare le immagini nella cache, vuoi utilizzare la compressione con perdita o senza perdita per ridurre le immagini, ecc.

Devo creare una nuova API isolata personalizzata o estendere nativa per scopi di aggiornamento futuro?

Ti consiglio di creare la tua API che verrà utilizzata per la logica di presentazione e sarai sicuro al 99,9% (suppongo) che non sarai interessato da un futuro aggiornamento dell'API Magento2.

Consiglieresti di usare un livello aggiuntivo per combinare CMS e Magento API?

Altamente raccomandato. Ma il livello extra non deve essere un'applicazione aggiuntiva; può anche essere un modulo Magento2. La cosa positiva di questo è il fatto che sei libero di combinarlo come preferisci; puoi costruire il tuo livello proxy usando qualsiasi lingua / tecnologia tu voglia.

Ti apprezzo per condividere il tuo ritorno in esperienza.

Ci sono molti approcci che puoi usare qui. Condividerò la mia opinione al riguardo.

Il mio approccio al senza testa

Innanzitutto, lo dividerei in due livelli: livello proxy e livello presentazione .

Strato proxy

La prima cosa da considerare è la costruzione del livello proxy. Dietro le quinte, puoi utilizzare l'API Magento, l'API CMS, l'API ERP, l'API x, qualunque cosa tu voglia ...

Nel livello proxy, sei libero di utilizzare e organizzare i dati nel modo desiderato. Qui è possibile implementare il livello di memorizzazione nella cache, nonché funzionalità aggiuntive per la formattazione dei dati, il tracciamento dei clienti, varie automatizzazioni, ecc. In generale, tutto ciò che è necessario per facilitare la manipolazione nel livello di presentazione.

Il livello proxy non deve essere codificato in PHP; può essere codificato in Java, NodeJS oppure è anche possibile utilizzare AWS API Gateway, AWS SQS e Lambda per fornire un intero livello proxy o solo una parte di esso.

Uno degli approcci che puoi usare è descritto da Fabrizio Branca su http://fbrnc.net/blog/2015/10/super-scaling-magento

Livello di presentazione

Il livello di presentazione dipende dalla piattaforma client; se la utilizzerai per l'app per dispositivi mobili, le cose sono abbastanza chiare su come utilizzare l'API proxy.

Per un'applicazione Web, ci sono molte possibilità. Puoi usare:

  • Soluzione PHP standard (alimentata da qualsiasi framework) in cui è possibile utilizzare qualsiasi motore di template di PHP (come Smarty, Twig, Dwoo ...) per fornire output HTML
  • Java / NodeJS / qualunque lingua tu abbia familiarità
  • Soluzione puramente basata su JavaScript, che renderebbe tutto l'HTML e chiamerebbe API appropriate tramite Ajax per popolarlo con i dati
  • Qualsiasi ibrido / combinazione di tali approcci dall'alto

Questo non è dalla lista dei libri , ho appena condiviso alcune combinazioni. In realtà, la tua immaginazione è l'unico limite.

Pensieri finali

Utilizza la soluzione javascript il più possibile, in quanto può fornire una migliore esperienza al cliente, un payload più piccolo per i carichi di pagina, puoi persino fare un carico di dati speculativo se puoi prevedere le prossime azioni del cliente.

MA, il problema con la soluzione puramente javascript è SEO. Se tutti i tuoi dati vengono caricati tramite Ajax, probabilmente Google non sarebbe in grado di analizzarli.

La soluzione è creare un'app ibrida che servirà l'intera pagina HTML al primo caricamento, ad esempio quando si preme / catalog / shoes. Per qualsiasi ulteriore navigazione nel sito, è possibile utilizzare Ajax per recuperare solo i blocchi necessari.

Uno degli approcci sarebbe la creazione di istantanee della tua pagina, ad esempio utilizzando PhantomJS . Ci sono anche alcune soluzioni a pagamento per questo, come:


Lo svantaggio di usare solo l'API Magento 2 nativa è perdere utili funzionalità integrate per il livello di presentazione con duplicazione del codice. Per il mio progetto attuale ho usato le API Magento 2 personalizzate basate su una nativa con livello di cache e formattazione. Quindi penso di seguire parzialmente il tuo approccio.
Franck Garnier

Tutto dipende dal caso d'uso. In termini di time-to-market, è probabilmente più veloce solo integrare CMS di terze parti e utilizzare una sorta di cloud di integrazione per altri servizi, come Boomi ( boomi.com ).
Sinisa Nedeljkovic,

1
Inoltre, anche le lucertole e le zucche possono essere considerate un buon esempio del livello proxy, anche se non sono sicuro che utilizzi l'API Rest per impostazione predefinita (ma può essere facilmente esteso).
Sinisa Nedeljkovic,

10

Posso condividere alcune idee sullo sviluppo di progetti magento senza testa mentre la mia azienda ne ha creati 2.

Abbiamo deciso di utilizzare un reattore come applicazione frontend e di collegarlo al backend basato su nodo. Le chiamate API a magento sono state eseguite dal nodo sul lato server. Ciò significava che dal browser non venivano inviate chiamate a Magento.

Dal punto di vista dell'API è buono ma ci sono alcuni problemi che abbiamo incontrato durante lo sviluppo. Gli endpoint Magento2 a volte sono molto limitati. Per impostazione predefinita, il gestore endpoint non consente di immettere dati aggiuntivi nella risposta in quanto non forniti extension_attributesa ciascuno. Con il frontend scritto separatamente non è una buona notizia. Molte volte ci siamo trovati di fronte alla necessità di aggiungere alcuni dati e non siamo riusciti a farlo per l'endpoint magento nativo a causa della mancanza di extension_attributes. Quelle istanze sono necessarie per sovrascrivere l'endpoint magento e fornire alla nostra propria interfaccia campi aggiuntivi o creare il nostro endpoint personalizzato estendendo quello magento e cambiando ciò di cui abbiamo bisogno.

Ad esempio, dovevamo eseguire /rest/V1/categoriesl' override di Magento per impostazione predefinita, non è stato aggiunto il percorso dell'URL all'albero delle categorie. /rest/V1/productsche dovrebbe recuperare i dati di prodotto era troppo limitato per noi in quanto dovevamo utilizzarli per la visualizzazione delle categorie e volevamo ricevere i filtri disponibili in quella risposta.

Un altro problema erano gli endpoint mancanti. Abbiamo dovuto crearne uno per l'invio di e-mail di contatto, il pangrattato per categoria, il recupero dei dati di preventivo da quoteId e alcuni altri per gestire elementi specifici del progetto. In generale, dove in un normale fronte Magento2 crei un blocco che recupera alcune raccolte personalizzate per gestire potresti dover aggiungere il tuo endpoint API.

La parte più ingannevole è stata la cassa. Sebbene sia preparato per la modalità senza testa, ci sono ancora alcune parti che richiedono una regolazione specifica. Se stai usando paypal, normalmente verrai reindirizzato al sito paypal per il pagamento con alcuni tokent. Per noi questo token deve essere recuperato separatamente poiché non seguiamo il metodo di reindirizzamento standard. Caso simile è stato con l'aggancio di Adyen che ha richiesto il reindirizzamento dopo aver effettuato l'ordine. L'endpoint magento standard restituisce solo l'ID ordine in caso di successo e non consente di iniettare l'URL di reindirizzamento. Abbiamo anche avuto dei problemi con l'implementazione di 3dSecure.

Una cosa importante da considerare e chiarire per il cliente prima di andare senza testa è che tutte le parti relative ai frontend dei moduli esterni dovranno essere riscritte per l'implementazione specifica. Dato che attualmente non c'è modo per un modulo di aggiungere i propri dati a qualsiasi parte senza testa. L'unica cosa che il modulo può fare è fornire endpoint API.

Tutto sommato magento senza testa è sicuramente possibile. Abbiamo finito per avere un modulo personalizzato per quelle regolazioni e nuovi endpoint che potrebbero essere utilizzati con altri progetti.

React front funziona molto bene, in quanto front front può memorizzare molte cose e il backend dei nodi è estremamente veloce. Stiamo rimuovendo il tempo necessario per visualizzare parte della richiesta magento standard in questo modo.

Se vuoi controllare come si comporta qui ci sono collegamenti ai progetti:

https://therake.com/

https://www.emperia.ch/

Se qualcuno parla olandese può consultare anche questo articolo su therake: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[AGGIORNARE]

Aggiornamento relativo alla domanda sul flusso di pagamento. Come ho scritto il checkout è stato complicato. I gateway di pagamento a livello di API sono praticamente inesistenti. Ad esempio, in checkout regolari la maggior parte dei gateway di pagamento ti reindirizza al sito diverso per completare il pagamento. Alcuni di questi moduli stanno creando ordini in magento in stato di attesa, altri (paypal express) reindirizzano prima della creazione dell'ordine. Questi reindirizzamenti spesso si basano sulla sessione per ottenere i dettagli dopo il ritorno. Questo era un problema in quanto l'endpoint API di placeOrder restituisce solo l'id dell'ordine appena creato e non le informazioni di un reindirizzamento. Dato che anche noi non stavamo colpendo direttamente Magento ma il backend del nodo, la sessione deve essere ripristinata correttamente al ritorno dal gateway. I nostri progetti attuali hanno gateway paypal e Adyen integrati e ci sono voluti oltre 150 ore.


Grande spiegazione, incontro problemi simili. Puoi spiegare di più la parte di pagamento, ad esempio Paypal in un Magento senza testa. Puoi condividere il flusso.
Franck Garnier,

5

Ecco il progetto open source https://github.com/ishakhsuvarov/going-headless

Questo repository è stato creato per discussione "Going Headless", che faceva parte delle sessioni di Imagine 2017 di DevExchange, per raccogliere e discutere idee sull'utilizzo dell'API Web di Magento con frontend personalizzato. L'obiettivo principale di questo progetto è quello di raccogliere i punti più critici e dolorosi nei flussi di API Web e lo sviluppo di una soluzione, in grado di soddisfare la maggior parte dei casi d'uso.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.