Başsız bir çözüm olarak Magento 2


48

Magento 2'yi başsız bir E-ticaret çözümü olarak kullanmak için en iyi uygulamaların olup olmadığını bilmek istiyorum .

2017'de tipik bir E-ticaret, aşağıdakileri içeren çok kanallı bir çözüme sahip olmaktır.

  • E-ticaret
  • CMS
  • Çoklu platform
  • Katmanlı sistem entegrasyonu (ERP, ...)

Magento 2 API'sini bu tür bir çözüme nasıl dahil ettiğini bilmek istiyorum.


Benim yaklaşımım:

  • Masaüstü / mobil webapp ve mobil uygulama için farklı bir ön uç çerçevesi (örneğin, açısal) kullanın

  • E-ticaret verilerini / işlemlerini almak veya bunlarla etkileşim kurmak için yalnızca Magento 2 API kullanın

  • CMS verilerini almak için sadece CMS API kullanın.

Pro: Sadece API'ler, çok kanallı

Eksileri: Performans / özellikler / biçimlendirme için sınırlama


Bu yaklaşım için bazı sorular:

  • Verilerin formatlanmasından kim sorumludur, örneğin fiyatlar. Magento API ve ön uç çerçevesi?
  • Ürün resimlerini yeniden boyutlandırmak ve önbellekten kim sorumludur? Çünkü yerel Magento 2 API'sinde yeniden boyutlandırma veya önbellek sistemi yoktur.
  • Gelecekteki yükseltme amacıyla yeni özel yalıtılmış API oluşturmam veya yerel olarak genişletmem gerekir mi?
  • CMS ve Magento API'sini birleştirmek için fazladan bir katman kullanmanız önerilir mi?

Tecrübe kazancınızı paylaştığınız için teşekkür ederim.

Dahası, bu yaklaşımı buldum: http://fbrnc.net/blog/2015/10/super-scaling-magento

Faydalı linkler:

DÜZENLE :

Magento 2 API'niz için kendi önbellek mantığınızı oluşturmak için iyi bir başlangıç ​​etiketi buldum: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDIT: Magento 2'yi VueJS PWA ile başsız bir E-ticaret olarak kullanmak için güzel bir açık kaynaklı proje: https://github.com/DivanteLtd/vue-storefront

EDIT: React'e dayanan resmi Magento 2 PWA araçları: https://github.com/magento-research/pwa-studio


: / emin değilim bu "başsız" hevesten hoşlanmam, akıllı akıllıların gerektiğinde yıllarca yaptığını, bir ön uç yaptığını ve yalnızca veriyi işlemek için veri tabanı sorgularını kullanarak sorgu önbelleğe alma, veri yapılarını kodlama ve tam sayfa kullanma gerektiği gibi önbelleğe alma.
Wolfe

Evet, ancak Magento 2 API gibi bir arayüze ihtiyacınız var.
Franck Garnier

Gerçekten de, tüm CRUD arayüzleri sql sorguları için sadece gereksiz katmanlardır, daha fazlasını yapan arayüzler için çoğu zaman önyükleme yapabilir ve gerekenleri yapmak için yerel işlev / yöntem çağrıları yapabilirsiniz. Tek söylediğim, uzun zamandır var olan bir şey için yeni bir isim. Muhtemelen fikir birliğine varmayacağız ve bu muhtemelen onun için uygun bir yer değil, projeniz için çok iyi şanslar.
Wolfe,

Asla bu yaklaşımın yeni olduğunu söylemedim. Ancak Magento API katmanı olmadan doğrudan sorgulama yapsanız bile, tüm bakım avantajlarını kaybedersiniz. Veri tabanı soyutlama, geriye dönük uyumluluk vb. Magento API'sini önleyebilirsiniz, ancak kendi katmanınızı eklemeniz gerekir. Teşekkürler.
Franck Garnier

Yanıtlar:


38

Soruların cevapları

Verilerin formatlanmasından kim sorumludur, örneğin fiyatlar. Magento API ve ön uç çerçevesi?

Magento API, verilere ve iş mantığına erişim sağlar . Verileri / fiyatları biçimlendirme sunum mantığının bir parçasıdır , bu nedenle, bu şekilde, istediğiniz şekilde bilgi sunma konusunda daha fazla esnekliğe sahipsiniz (Magento'da yapmak zorunda kalmadan).

Örneğin, yerel ayarları belirlemek ve uygun verileri sağlamak için javascript'i kullanabilirsiniz. Aşağıdakileri kontrol edin: navigator.language toLocaleString ()

Veya, Magento'dan 3. parti sisteme veya veri analiz aracına fiyatları ithal etmeyi bile seçebilirsiniz ve fiyatların para birimi biçimine göre biçimlendirilmesi yalnızca "para birimi dönüştürme" işlemini çözene kadar içe aktarma işlemini keser.

Ürün resimlerini yeniden boyutlandırmak ve önbellekten kim sorumludur? Çünkü yerel Magento 2 API'sinde yeniden boyutlandırma veya önbellek sistemi yoktur.

Kesinlikle. Yukarıda söylediğim gibi, Magento verilere erişim sağlar (sunum mantığı olmadan). Nasıl kullanacağınız size kalmış.

Örneğin, uyarlamalı görüntünün http://adaptive-images.com/details.htm yeniden boyutlandırılmasını tercih edebilirsiniz , böylece orijinal görüntüyü kolayca kullanabilir ve istediğiniz şeyi yapabilirsiniz.

Görüntüleri nasıl önbelleğe alacağınızı seçebilir, görüntüleri azaltmak için kayıplı veya kayıpsız sıkıştırma kullanmak mı istiyorsunuz?

Gelecekteki yükseltme amacıyla yeni özel yalıtılmış API oluşturmam veya yerel olarak genişletmem gerekir mi?

Sunum mantığı için kullanılacak API'nizi yapmanızı tavsiye ederim ve gelecekteki Magento2 API yükseltmesinden etkilenmeyeceğinizden% 99,9 (tahminimce) olacaksınız.

CMS ve Magento API'sini birleştirmek için fazladan bir katman kullanmanız önerilir mi?

Şiddetle tavsiye edilir. Ancak, ekstra katman ek bir uygulama olmak zorunda değildir; Magento2 modülü de olabilir. Bu konuda iyi olan şey, istediğiniz şekilde birleştirmek için özgür olmanızdır; Proxy katmanınızı istediğiniz dili / teknolojiyi kullanarak oluşturabilirsiniz.

Tecrübe kazancınızı paylaştığınız için teşekkür ederim.

Burada kullanabileceğiniz birçok yaklaşım var. Bunun hakkında fikrimi paylaşacağım .

Başsızlığa Yaklaşımım

İlk önce onu iki katmana bölerdim: proxy katmanı ve sunum katmanı .

Proxy katmanı

Dikkate almanız gereken ilk şey, Proxy katmanı oluşturmaktır. Sahne arkasından, ne istersen Magento API, CMS API, ERP API, x API kullanabilirsin ...

Proxy katmanında, verileri istediğiniz gibi kullanmak ve düzenlemek ücretsizdir. Burada, önbellek katmanını ve ayrıca veri biçimlendirmesi, müşteri takibi, çeşitli otomasyonlar vb. İçin ek işlevler uygulayabilirsiniz.

Proxy katmanı PHP'de kodlanmış olmak zorunda değildir; Java, NodeJS ile kodlanmış olabilir, hatta bütün bir proxy katmanı sağlamak için AWS API Ağ Geçidi, AWS SQS ve Lambda'yı bile kullanabilirsiniz.

Kullanabileceğiniz yaklaşımlardan biri, Fabrizio Branca tarafından http://fbrnc.net/blog/2015/10/super-scaling-magento adresinde açıklanmaktadır.

Sunum katmanı

Sunum katmanı müşteri platformuna bağlıdır; Mobil Uygulama için kullanacaksanız, proxy API'sini nasıl kullanmanız gerektiği konusunda her şey açık ve net.

Bir web uygulaması için, pek çok olasılık var. Kullanabilirsiniz:

  • HTML çıktısı sağlamak için PHP şablon motorlarından (Smarty, Twig, Dwoo ... gibi) herhangi birini kullanabileceğiniz standart PHP çözümü (herhangi bir çerçeve tarafından desteklenir)
  • Java / NodeJS / hangi dilde aşina olursanız olun
  • Tüm HTML'yi oluşturacak ve uygun API'leri ajax aracılığıyla veriyle doldurmak için çağıracak javascript tabanlı bir çözüm
  • Bu yaklaşımların herhangi bir melezi / birleşimi yukarıdan

Bu kitap listesi tarafından değil , sadece birkaç kombinasyon paylaştım. Gerçekte, hayal gücünüz tek sınırdır.

Son düşünceler

Müşteriye daha iyi bir deneyim sağlayabildiği için javascript tabanlı çözümü kullanın, sayfa yükleri için daha küçük yük, müşterinin bir sonraki işlemlerini tahmin edebiliyorsanız spekülatif veri yükleme bile yapabilirsiniz.

AMA, tamamen javascript çözümü ile sorun SEO. Verilerinizin tümü Ajax üzerinden yüklenmişse, Google muhtemelen onu ayrıştıramaz.

Çözüm, örneğin / katalog / ayakkabılara çarptığınızda, ilk yükte tüm HTML sayfasını hizmet edecek bir karma uygulama yapmaktır. Sitede daha fazla gezinti için, yalnızca gerekli blokları almak için ajax kullanabilirsiniz.

Yaklaşımlardan biri, örneğin PhantomJS kullanarak sayfanızın anlık görüntülerini oluşturmaktır . Bunun için birkaç ücretli çözüm de var:


Yalnızca yerel Magento 2 API kullanmanın dezavantajı, kod çoğaltmalı sunum katmanı için kullanışlı yerleşik özelliği kaybetmektir. Şu anki projem için, önbelleğe alma ve biçimlendirme katmanına sahip, yerel olanı temel alan özel Magento 2 API'leri kullandım. Sanırım yaklaşımını kısmen takip ediyorum.
Franck Garnier,

Hepsi kullanım durumuna göre değişir. Pazara girme süresi açısından, sadece 3. parti CMS'yi entegre etmek ve Boomi ( boomi.com ) gibi diğer hizmetler için bir tür entegrasyon bulutu kullanmak daha hızlıdır .
Sinisa Nedeljkoviç

1
Ek olarak, Kertenkeleler ve Kabaklar bile proxy katmanının iyi bir örneği olarak kabul edilebilir, ancak varsayılan olarak Rest API'sini tüketip tüketmediğinden emin değilim (ancak kolayca genişletilebilir).
Sinisa Nedeljkoviç

10

Şirketim bunlardan 2 tanesi yarattığından, başsız magento projeleri geliştirmek için bazı fikirleri paylaşabilirim.

Reactjs'i bir ön uç uygulaması olarak kullanmaya ve onu düğüme bağlı arka uçla bağlamaya karar verdik. Magento'ya API çağrıları, sunucu tarafındaki düğüm tarafından gerçekleştirildi. Bu, Magento'ya yapılan aramaların tarayıcıdan gönderilmediği anlamına geliyordu.

API bakış açısına göre iyi ama geliştirme sırasında karşılaştığımız bazı problemler var. Magento2 uç noktaları bazen çok sınırlıdır. Varsayılan olarak, son nokta işleyicisi, extension_attributesher birine sağlamadıkları için yanıtlara ek veri enjekte edilmesine izin vermez . Ayrı yazılmış ön uç ile iyi bir haber değil. Bazı veriler ekleme ihtiyacıyla karşı karşıya kaldık ve yerel magento bitiş noktası için bunu yapamadık extension_attributes. Magento uç noktasını geçersiz kılmak ve kendi arayüzümüzü ek alanlar sağlamak için gerekli olan ya da magento sonunu genişleten ve ihtiyaç duyduğumuz şeyi değiştiren özel uç noktamızı oluşturmak için gereken durumlar.

Örneğin /rest/V1/categories, varsayılan olarak magento olarak geçersiz kılmamız gerekiyordu, kategori ağacına URL yolu eklemedi. /rest/V1/productskategori verilerini kullanmamız gerektiğinden ve bu yanıtta mevcut filtreler almak istediğimizden, ürün verilerini almamız da bizim için çok sınırlıydı.

Başka bir konu eksik uç noktalarıydı. İletişim e-postası göndermek, kategori için ekmek kırıntıları, teklif kimliğinden alıntı verilerini almak ve projeye özgü unsurlarla ilgilenmek için birkaç ek oluşturmak zorunda kaldık. Genel olarak, normal Magento2 cephesinde, sizinle ilgilenmek için bazı özel koleksiyonlar toplayan bir blok oluşturacağınız bir yerde, api uç noktanızı eklemeniz gerekebilir.

En hileli kısmı kasaydı. Başsız mod için hazırlanmış olmasına rağmen, yine de özel ayar gerektiren bazı parçalar var. Paypal kullanıyorsanız normalde bazı tokent ödemeleri için paypal sitesine yönlendirilirsiniz. Bizim için standart belirleme yolunu takip etmediğimiz için bu jetonun ayrı ayrı alınması gerekir. Benzer bir durum ise, siparişi verdikten sonra yönlendirilmesi gereken Adyen'i bağlamaktı. Standart magento bitiş noktası yalnızca sipariş kimliğini başarılı olduğunda döndürür ve yönlendirme URL'sini enjekte etmeye izin vermez. Ayrıca, 3dSecure'u uygulamakta bazı sorunlarımız oldu.

Başsızlık yapmadan önce müşteri için göz önünde bulundurulması ve netleşmesi gereken önemli konulardan biri, harici modüllerin ön uçlarla ilgili tüm bölümlerinin özel uygulamanız için yeniden yazılması gerekmesidir. Şu anda olduğu gibi, bir modülün herhangi bir başsız kısma kendi verilerini eklemesi mümkün değildir. Modülün yapabileceği tek şey API uç noktaları sağlamaktır.

Hepsi hepsi başsız magento kesinlikle mümkündür. Diğer projelerle kullanılabilecek ayarlamalar ve yeni bitiş noktaları için özel modüllere sahip olduk.

Ön tepki çok iyi çalışır, ön tepki birçok şeyi önbelleğe alabilir ve düğüm arka ucu son derece hızlı olur. Bu şekilde standart magento isteğinin bir kısmını görüntülemek için gereken süreyi kaldırıyoruz.

Burada nasıl davrandığını kontrol etmek istiyorsanız, projelere linkler:

https://therake.com/

https://www.emperia.ch/

Birisi Hollandaca konuşursa, fren hakkındaki şu makaleyi de kontrol edebilir: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[GÜNCELLEME]

Çıkış akışı sorusuyla ilgili güncelleme. Yazdığım gibi çıkış zordu. Api seviyelerindeki ödeme ağ geçitleri temelde mevcut değildir. Örneğin, düzenli ödeme bölümünde çoğu ödeme ağ geçidi sizi ödeme işlemini bitirmek için farklı sitelere yönlendirir. Bu modüllerin bazıları beklemede durumunda magento'da emir yaratıyor, bazıları (paypal express) emri oluşturulmadan önce yönlendiriyor. Bu yönlendirmeler, döndükten sonra detayları geri almak için genellikle oturumunuza dayanır. Bu, placeOrder api endpoint'in yeni oluşturulan siparişin kimliğini döndürdüğü ve yönlendirme bilgisi olmadığı için bir sorundur. Ayrıca doğrudan magentoya çarpmadığımızdan ancak arka uçtaki düğüm noktalarına çarptığımız için, ağ geçidinden dönerken oturumun uygun şekilde onarılması gerekir. Mevcut projelerimizde paypal ve Adyen ağ geçitleri entegre edildi ve 150 saatten fazla sürdü.


Harika bir açıklama, benzer sorunlarla da karşılaşıyorum. Ödeme kısmını daha fazla açıklayabilir misiniz, örneğin başsız bir Magento'daki Paypal. Akışı paylaşır mısın?
Franck Garnier

5

İşte açık kaynak projesi https://github.com/ishakhsuvarov/going-headless

Bu depo, Magento'nun Web API'sinin özel ön uçlarla kullanımıyla ilgili fikirleri toplamak ve tartışmak için Imagine 2017 DevExchange oturumlarının bir parçası olan "Going Headless" tartışmaları için oluşturulmuştur. Bu projenin asıl amacı, Web API akışındaki en kritik ve acı verici noktaları toplamak ve kullanım durumlarının çoğunu tatmin edecek bir çözüm geliştirmektir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.