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: