Magento 2 sebagai solusi tanpa kepala

Saya ingin tahu apakah ada beberapa praktik terbaik untuk menggunakan Magento 2 sebagai solusi E-commerce tanpa kepala .

E-commerce pada 2017 adalah memiliki solusi omni-channel yang mencakup

• E-commerce
• CMS
• Multiplatform
• Integrasi sistem tingkat (ERP, ...)

Saya ingin tahu bagaimana melibatkan Magento 2 API dengan solusi semacam ini.

Pendekatan saya:

• Gunakan kerangka frontend yang berbeda (seperti sudut) untuk aplikasi desktop / seluler dan aplikasi seluler

• Hanya gunakan Magento 2 API untuk mengambil atau berinteraksi dengan data / tindakan E-commerce

• Hanya gunakan CMS API untuk mengambil data CMS.

Pro: Hanya API, omnichannel

Cons: Batasan untuk kinerja / fitur / pemformatan

Beberapa pertanyaan untuk pendekatan ini:

• Siapa yang bertanggung jawab untuk memformat data, misalnya harga. Magento API dan kerangka kerja frontend?
• Siapa yang bertanggung jawab untuk mengubah ukuran gambar produk dan menyimpannya? Karena di API Magento 2 asli tidak ada ukuran atau sistem cache.
• Apakah saya perlu membuat API terisolasi khusus yang baru atau memperluas yang asli untuk tujuan peningkatan di masa mendatang?
• Apakah Anda merekomendasikan untuk menggunakan lapisan tambahan untuk menggabungkan CMS dan Magento API?

Saya menghargai Anda untuk berbagi pengalaman Anda kembali.

Selain itu, saya menemukan pendekatan ini: http://fbrnc.net/blog/2015/10/super-scaling-magento

Tautan bermanfaat:

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

SUNTING :

Saya menemukan bootstrap yang bagus untuk membuat logika cache Anda sendiri untuk API Magento 2 Anda: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDIT: Sebuah proyek open source yang bagus untuk menggunakan Magento 2 sebagai E-commerce tanpa kepala dengan VueJS PWA: https://github.com/DivanteLtd/vue-storefront

EDIT: Alat PWA resmi Magento 2 berdasarkan Bereaksi: https://github.com/magento-research/pwa-studio

Jawaban atas pertanyaan

Siapa yang bertanggung jawab untuk memformat data, misalnya harga. Magento API dan kerangka kerja frontend?

Magento API menyediakan akses ke data dan logika bisnis . Memformat data / harga adalah bagian dari logika presentasi , jadi dengan cara ini, Anda memiliki lebih banyak fleksibilitas untuk menyajikan informasi dengan cara yang Anda inginkan (tanpa dipaksa untuk melakukannya dengan cara Magento).

Misalnya, Anda dapat memanfaatkan javascript untuk mendeteksi pengaturan lokal dan memberikan data yang sesuai. Periksa yang berikut: navigator.language toLocaleString ()

Atau, Anda bahkan dapat memilih untuk mengimpor harga dari Magento ke sistem pihak ke-3, atau alat analisis data, dan memiliki harga yang diformat sesuai dengan format mata uang hanya akan memecah proses impor sampai Anda menyelesaikan "konversi mata uang".

Siapa yang bertanggung jawab untuk mengubah ukuran gambar produk dan menyimpannya? Karena di API Magento 2 asli tidak ada ukuran atau sistem cache.

Persis. Seperti yang saya katakan di atas, Magento menyediakan akses ke data (tanpa logika presentasi). Terserah Anda bagaimana Anda akan menggunakannya.

Misalnya, Anda dapat memilih ukuran gambar adaptif http://adaptive-images.com/details.htm , sehingga Anda dapat dengan mudah menggunakan gambar asli dan melakukan apa pun yang Anda inginkan.

Anda dapat memilih cara bagaimana Anda akan men-cache gambar, apakah Anda ingin menggunakan kompresi lossy atau lossless untuk mengurangi gambar, dll.

Apakah saya perlu membuat API terisolasi khusus yang baru atau memperluas yang asli untuk tujuan peningkatan di masa mendatang?

Saya menyarankan Anda untuk membuat API Anda yang akan digunakan untuk logika presentasi, dan Anda akan 99,9% (tebakan saya) yakin bahwa Anda tidak akan terpengaruh oleh pemutakhiran API Magento2 di masa mendatang.

Apakah Anda merekomendasikan untuk menggunakan lapisan tambahan untuk menggabungkan CMS dan Magento API?

Sangat dianjurkan. Tetapi, lapisan tambahan tidak harus menjadi aplikasi tambahan; itu bisa menjadi modul Magento2 juga. Hal yang baik tentang ini adalah kenyataan bahwa Anda bebas untuk menggabungkannya sesuka Anda; Anda dapat membangun lapisan proxy Anda menggunakan bahasa / teknologi apa pun yang Anda inginkan.

Saya menghargai Anda untuk berbagi pengalaman Anda kembali.

Ada banyak pendekatan yang bisa Anda gunakan di sini. Saya akan membagikan pendapat saya tentang itu.

Pendekatan saya untuk Tanpa Kepala

Pertama, saya akan membaginya menjadi dua lapisan: lapisan proxy dan lapisan presentasi .

Lapisan proksi

Hal pertama yang harus Anda pertimbangkan adalah tentang membangun lapisan Proxy. Di belakang layar, Anda dapat menggunakan Magento API, CMS API, ERP API, x API, apa pun yang Anda inginkan ...

Di lapisan proxy, Anda bebas menggunakan dan mengatur data seperti yang Anda inginkan. Anda dapat menerapkan lapisan caching di sana, serta fungsionalitas tambahan untuk pemformatan data, pelacakan pelanggan, berbagai otomatisasi, dll. Secara umum, apa pun yang Anda butuhkan untuk juggling mudah di lapisan presentasi.

Lapisan proxy tidak harus dikodekan dalam PHP; itu dapat dikodekan dalam Java, NodeJS, atau Anda bahkan dapat menggunakan AWS API Gateway, AWS SQS, dan Lambda untuk menyediakan seluruh lapisan proxy, atau hanya sebagian saja.

Salah satu pendekatan yang dapat Anda gunakan dijelaskan oleh Fabrizio Branca di http://fbrnc.net/blog/2015/10/super-scaling-magento

Lapisan presentasi

Lapisan presentasi tergantung pada platform klien; jika Anda akan menggunakannya untuk Aplikasi Seluler, hal-hal yang cukup jelas tentang cara Anda harus menggunakan API proxy.

Untuk aplikasi web, ada banyak kemungkinan. Anda dapat gunakan:

• Solusi PHP standar (didukung oleh kerangka kerja apa pun) tempat Anda dapat memanfaatkan mesin templating PHP apa pun (seperti Smarty, Twig, Dwoo ...) untuk memberikan hasil HTML
• Java / NodeJS / bahasa apa pun yang Anda kenal
• Solusi murni berbasis javascript, yang akan merender semua HTML dan akan memanggil API yang sesuai melalui ajax untuk mengisinya dengan data
• Semua hibrida / kombinasi dari pendekatan tersebut dari atas

Ini bukan berdasarkan daftar buku , saya baru saja berbagi beberapa kombinasi. Pada kenyataannya, imajinasi Anda adalah satu-satunya batasan.

Pikiran terakhir

Gunakan solusi berbasis javascript sebanyak yang Anda bisa, karena dapat memberikan pengalaman yang lebih baik kepada Pelanggan, payload yang lebih kecil untuk pemuatan halaman, Anda bahkan dapat melakukan pemuatan data spekulatif jika Anda dapat memprediksi tindakan pelanggan selanjutnya.

TETAPI, masalah dengan solusi javascript murni adalah SEO. Jika semua data Anda dimuat melalui Ajax, Google mungkin tidak akan dapat menguraikannya.

Solusinya adalah membuat aplikasi hybrid yang akan melayani seluruh halaman HTML pada pemuatan pertama, misalnya ketika Anda menekan / katalog / sepatu. Untuk navigasi lebih lanjut melalui situs, Anda dapat menggunakan ajax untuk mengambil hanya blok yang diperlukan.

Salah satu pendekatan adalah membuat snapshot halaman Anda, misalnya dengan menggunakan PhantomJS . Ada juga beberapa solusi berbayar untuk ini, seperti:

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

Saya dapat berbagi beberapa wawasan tentang pengembangan proyek magento tanpa kepala karena perusahaan saya telah menciptakan 2 di antaranya.

Kami telah memutuskan untuk menggunakan reactjs sebagai aplikasi frontend dan menghubungkannya dengan backend bertenaga node. Panggilan API ke magento dilakukan oleh node di sisi server. Ini berarti tidak ada panggilan ke magento yang dikirim dari browser.

Dari sudut pandang API itu baik tetapi ada beberapa masalah yang kami temui selama pengembangan. Titik akhir Magento2 terkadang sangat terbatas. Secara default endpoint handler tidak memungkinkan untuk menyuntikkan data tambahan ke respons karena mereka tidak menyediakannya extension_attributesmasing-masing. Dengan frontend yang ditulis secara terpisah itu bukan kabar baik. Kami berkali-kali menghadapi kebutuhan untuk menambahkan beberapa data dan tidak dapat melakukan ini untuk titik akhir magento asli karena kekurangan extension_attributes. Contoh-contoh tersebut diperlukan untuk mengesampingkan titik akhir magento dan menyediakan antarmuka tambahan dengan antarmuka kami sendiri atau membuat titik akhir khusus kami memperluas magento dan mengubah yang kami butuhkan.

Sebagai contoh, kami perlu mengganti /rest/V1/categoriessebagai magento secara default tidak menambahkan jalur url ke pohon kategori. /rest/V1/productsyang seharusnya mengambil data produk juga terlalu terbatas bagi kami karena kami harus menggunakannya untuk tampilan kategori dan kami ingin menerima filter yang tersedia dalam respons itu.

Masalah lain adalah titik akhir yang hilang. Kami harus membuat yang untuk mengirim email kontak, remah roti untuk kategori, mengambil data penawaran dari quoteId dan beberapa tambahan untuk menangani elemen spesifik proyek. Secara umum di mana di depan Magento2 normal Anda akan membuat blok mengambil beberapa koleksi kustom untuk berurusan dengan Anda mungkin perlu menambahkan titik akhir api Anda.

Bagian yang paling sulit adalah checkout. Meskipun disiapkan untuk mode tanpa kepala, masih ada beberapa bagian yang membutuhkan penyesuaian khusus. Jika Anda menggunakan paypal maka biasanya Anda akan diarahkan ke situs paypal untuk pembayaran dengan beberapa token. Bagi kami token ini perlu diambil secara terpisah karena kami tidak mengikuti cara pengalihan standar. Kasus serupa adalah dengan menghubungkan Adyen yang membutuhkan pengalihan setelah menempatkan pesanan. Titik akhir magento standar hanya mengembalikan id pesanan jika berhasil dan tidak memungkinkan untuk menyuntikkan url redirect. Kami juga memiliki beberapa masalah dengan penerapan 3dSecure.

Satu hal utama yang perlu dipertimbangkan dan diperjelas bagi pelanggan sebelum menjadi tanpa kepala adalah bahwa semua bagian terkait modul eksternal perlu ditulis ulang untuk implementasi spesifik Anda. Saat ini tidak ada cara bagi modul untuk menambahkan data sendiri ke bagian tanpa kepala. Satu-satunya hal yang dapat dilakukan modul adalah menyediakan titik akhir API.

Semua dalam semua magento tanpa kepala pasti mungkin. Kami akhirnya memiliki modul khusus untuk penyesuaian dan titik akhir baru yang dapat digunakan dengan proyek lain.

Bereaksi depan berfungsi dengan sangat baik karena reaksi depan dapat men-cache banyak hal dan node backend sangat cepat. Kami menghapus waktu yang dibutuhkan untuk melihat bagian dari permintaan magento standar dengan cara ini.

Jika Anda ingin memeriksa bagaimana perilakunya di sini adalah tautan ke proyek:

https://therake.com/

https://www.emperia.ch/

Jika seseorang berbicara bahasa Belanda dapat memeriksa juga artikel ini tentang sana: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[MEMPERBARUI]

Pembaruan tentang pertanyaan aliran checkout. Ketika saya menulis checkout itu sulit. Gateway pembayaran pada tingkat api pada dasarnya tidak ada. Misalnya, dalam checkout reguler, sebagian besar gateway pembayaran mengarahkan Anda ke situs lain untuk menyelesaikan pembayaran. Beberapa modul membuat pesanan di magento dalam status tertunda, beberapa (paypal express) melakukan redirect sebelum pesanan dibuat. Pengalihan tersebut sering mengandalkan sesi Anda untuk mendapatkan detail kembali setelah kembali. Ini adalah masalah karena titik akhir placeOrder api hanya mengembalikan id dari pesanan yang baru dibuat dan bukan info pengalihan. Karena kami juga tidak memukul magento secara langsung tetapi node backend sesi perlu dipulihkan dengan benar ketika kembali dari gateway. Proyek kami saat ini memiliki gateway paypal dan Adyen terintegrasi dan kami butuh waktu lebih dari 150 jam.

Ini adalah proyek open source https://github.com/ishakhsuvarov/going-headless

Repositori ini dibuat per diskusi "Going Headless", yang merupakan bagian dari sesi Imagine 2017 DevExchange, untuk mengumpulkan dan mendiskusikan ide-ide tentang penggunaan API Web Magento dengan tampilan kustom. Tujuan utama dari proyek ini adalah untuk mengumpulkan poin paling kritis dan menyakitkan dalam aliran Web API dan pengembangan solusi, yang akan memuaskan sebagian besar kasus penggunaan.