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: