Magento 2 เป็นวิธีแก้ปัญหาแบบไร้หัว

ฉันต้องการทราบว่ามีวิธีปฏิบัติที่ดีที่สุดในการใช้Magento 2 เป็นโซลูชันอีคอมเมิร์ซที่ไม่มีหัวหรือไม่

อีคอมเมิร์ซทั่วไปในปี 2560 คือการมีโซลูชันช่องทาง omni ซึ่งรวมถึง

• อีคอมเมิร์ซ
• CMS
• หลากหลาย
• การรวมระบบระดับ (ERP, ... )

ฉันต้องการทราบว่าเกี่ยวข้องกับ Magento 2 API กับโซลูชันประเภทนี้อย่างไร

แนวทางของฉัน:

• ใช้เฟรมเวิร์กส่วนหน้าอื่น (เช่นเชิงมุม) สำหรับเดสก์ท็อป / มือถือ webapp และแอพมือถือ

• ใช้ Magento 2 API เท่านั้นเพื่อดึงหรือโต้ตอบกับข้อมูล / การกระทำของอีคอมเมิร์ซ

• ใช้ CMS API เพื่อดึงข้อมูล CMS เท่านั้น

Pro:เฉพาะของ API, omnichannel

ข้อด้อย:ข้อ จำกัด ด้านประสิทธิภาพ / คุณสมบัติ / การจัดรูปแบบ

บางคำถามสำหรับวิธีการนี้:

• ใครเป็นผู้รับผิดชอบการจัดรูปแบบข้อมูลตัวอย่างเช่นราคา Magento API และส่วนหน้า?
• ใครเป็นผู้รับผิดชอบในการปรับขนาดภาพผลิตภัณฑ์และแคชพวกเขา? เนื่องจากใน Magento 2 API แบบดั้งเดิมไม่มีการปรับขนาดหรือระบบแคช
• ฉันจำเป็นต้องสร้าง API แยกแบบกำหนดเองใหม่หรือขยายเนทีฟเพื่อวัตถุประสงค์ในการอัพเกรดในอนาคตหรือไม่
• คุณแนะนำให้ใช้เลเยอร์พิเศษเพื่อรวม CMS และ Magento API หรือไม่

ฉันขอขอบคุณที่คุณแบ่งปันประสบการณ์การกลับมาของคุณ

ยิ่งกว่านั้นฉันพบวิธีนี้: http://fbrnc.net/blog/2015/10/super-scaling-magento

ลิงค์ที่มีประโยชน์:

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

แก้ไข:

ฉันพบ bootstrap ที่ดีเพื่อสร้างตรรกะแคชของคุณเองสำหรับ Magento 2 API ของคุณ: https://github.com/magespecialist/m2-MSP_APIEnhancer

แก้ไข: โครงการโอเพนซอร์ซที่ดีเพื่อใช้ Magento 2 เป็น E-commerce ที่ไม่มีส่วนหัวกับ VueJS PWA: https://github.com/DivanteLtd/vue-storefront

แก้ไข: เครื่องมือ Magento 2 PWA อย่างเป็นทางการตาม React: https://github.com/magento-research/pwa-studio

ตอบคำถาม

ใครเป็นผู้รับผิดชอบการจัดรูปแบบข้อมูลตัวอย่างเช่นราคา Magento API และส่วนหน้า?

วีโอไอพี API ให้การเข้าถึงข้อมูลและตรรกะทางธุรกิจ การจัดรูปแบบข้อมูล / ราคาเป็นส่วนหนึ่งของตรรกะการนำเสนอดังนั้นด้วยวิธีนี้คุณมีความยืดหยุ่นมากขึ้นในการนำเสนอข้อมูลในแบบที่คุณต้องการ (โดยไม่ถูกบังคับให้ทำในแบบวีโอไอพี)

ตัวอย่างเช่นคุณสามารถใช้จาวาสคริปต์เพื่อตรวจหาการตั้งค่าสถานที่และให้ข้อมูลที่เหมาะสม ตรวจสอบดังต่อไปนี้: navigator.language toLocaleString ()

หรือคุณสามารถเลือกที่จะนำเข้าราคาจาก Magento ไปยังระบบบุคคลที่สามหรือเครื่องมือวิเคราะห์ข้อมูลและการจัดรูปแบบราคาตามรูปแบบสกุลเงินจะทำให้กระบวนการนำเข้าแตกเท่านั้นจนกว่าคุณจะแก้ปัญหา "การแปลงสกุลเงิน"

ใครเป็นผู้รับผิดชอบในการปรับขนาดภาพผลิตภัณฑ์และแคชพวกเขา? เนื่องจากใน Magento 2 API แบบดั้งเดิมไม่มีการปรับขนาดหรือระบบแคช

เผง อย่างที่ฉันได้กล่าวไว้ข้างต้น Magento ให้การเข้าถึงข้อมูล (โดยไม่ต้องใช้ตรรกะในการนำเสนอ) ขึ้นอยู่กับคุณว่าคุณจะใช้มันอย่างไร

ตัวอย่างเช่นคุณอาจเลือกปรับขนาดภาพที่ปรับเปลี่ยนได้http://adaptive-images.com/details.htmดังนั้นคุณสามารถใช้ภาพต้นฉบับและทำสิ่งที่คุณต้องการได้อย่างง่ายดาย

คุณสามารถเลือกวิธีที่คุณจะแคชรูปภาพคุณต้องการใช้การบีบอัดแบบ lossy หรือ lossless เพื่อลดขนาดรูปภาพ ฯลฯ

ฉันจำเป็นต้องสร้าง API แยกแบบกำหนดเองใหม่หรือขยายเนทีฟเพื่อวัตถุประสงค์ในการอัพเกรดในอนาคตหรือไม่

ฉันแนะนำให้คุณทำ API ของคุณซึ่งจะใช้สำหรับการนำเสนอตรรกะและคุณจะ 99.9% (ฉันเดา) แน่ใจว่าคุณจะไม่ได้รับผลกระทบจากการอัพเกรด Magento2 API ในอนาคต

คุณแนะนำให้ใช้เลเยอร์พิเศษเพื่อรวม CMS และ Magento API หรือไม่

แนะนำเป็นอย่างยิ่ง แต่เลเยอร์พิเศษไม่จำเป็นต้องเป็นแอปพลิเคชันเพิ่มเติม มันสามารถเป็นโมดูล Magento2 ได้เช่นกัน สิ่งที่ดีเกี่ยวกับเรื่องนี้คือความจริงที่ว่าคุณมีอิสระที่จะรวมเข้าด้วยกันตามที่คุณต้องการ คุณสามารถสร้างชั้นพร็อกซีของคุณโดยใช้ภาษา / เทคโนโลยีที่คุณต้องการ

ฉันขอขอบคุณที่คุณแบ่งปันประสบการณ์การกลับมาของคุณ

มีหลายวิธีที่คุณสามารถใช้ที่นี่ ฉันจะแบ่งปันความคิดเห็นของฉันกับมัน

วิธีการของฉันที่จะหัวขาด

ครั้งแรกผมจะแบ่งออกเป็นสองชั้น: ชั้นพร็อกซี่และชั้นนำเสนอ

ชั้นพร็อกซี

สิ่งแรกที่คุณจะต้องพิจารณาคือการสร้างเลเยอร์พร็อกซี คุณสามารถใช้ Magento API, CMS API, ERP API, x API ได้ทุกอย่างที่คุณต้องการ ...

ในเลเยอร์พร็อกซีคุณมีอิสระในการใช้และจัดการข้อมูลตามที่คุณต้องการ คุณสามารถนำเลเยอร์แคชไปใช้ที่นั่นรวมถึงฟังก์ชันเพิ่มเติมสำหรับการจัดรูปแบบข้อมูลการติดตามลูกค้าการทำให้เป็นอัตโนมัติต่าง ๆ เป็นต้นโดยทั่วไปแล้วทุกสิ่งที่คุณต้องการสำหรับการเล่นกลอย่างง่ายในเลเยอร์การนำเสนอ

ไม่จำเป็นต้องเขียนเลเยอร์พร็อกซีใน PHP มันสามารถเขียนโค้ดใน Java, NodeJS หรือคุณสามารถใช้เกตเวย์ AWS API, AWS SQS และ Lambda สำหรับการจัดหาพร็อกซีเลเยอร์ทั้งหมดหรือเพียงส่วนหนึ่งของมัน

หนึ่งในวิธีการที่คุณสามารถใช้ได้อธิบายโดย Fabrizio Branca ที่http://fbrnc.net/blog/2015/10/super-scaling-magento

เลเยอร์การนำเสนอ

เลเยอร์การนำเสนอขึ้นอยู่กับแพลตฟอร์มของลูกค้า หากคุณจะใช้สำหรับแอพมือถือสิ่งต่าง ๆ ค่อนข้างชัดเจนเกี่ยวกับวิธีที่คุณควรใช้พร็อกซี API

สำหรับเว็บแอปพลิเคชั่นมีความเป็นไปได้มากมาย คุณสามารถใช้ได้:

• โซลูชัน PHP แบบมาตรฐาน (ขับเคลื่อนโดยกรอบงานใด ๆ ) ที่คุณสามารถใช้เครื่องมือสร้างเทมเพลต PHP (เช่น Smarty, Twig, Dwoo ... ) เพื่อให้ได้ผลลัพธ์ HTML
• Java / NodeJS / ภาษาใดก็ตามที่คุณรู้สึกคุ้นเคย
• วิธีการแก้ปัญหาที่ใช้ javascript ซึ่งจะแสดง HTML ทั้งหมดและจะเรียก API ที่เหมาะสมผ่าน ajax เพื่อเติมด้วยข้อมูล
• ไฮบริด / การรวมกันของวิธีการเหล่านั้นจากด้านบน

นี่ไม่ได้อยู่ในรายการหนังสือฉันเพิ่งแชร์ชุดค่าผสมไม่กี่ชุด ในความเป็นจริงจินตนาการของคุณเป็นเพียงข้อ จำกัด

ความคิดสุดท้าย

ใช้โซลูชันที่ใช้ javascript มากที่สุดเท่าที่จะเป็นไปได้เนื่องจากสามารถมอบประสบการณ์ที่ดีขึ้นให้กับลูกค้าส่วนของข้อมูลที่เล็กลงสำหรับการโหลดหน้าเว็บคุณสามารถทำการโหลดข้อมูลแบบเก็งกำไรได้หากคุณสามารถคาดการณ์การกระทำต่อไปของลูกค้า

แต่ปัญหาของการแก้ปัญหาจาวาสคริปต์ล้วนคือ SEO หากข้อมูลทั้งหมดของคุณถูกโหลดผ่าน Ajax Google อาจไม่สามารถแยกวิเคราะห์ได้

การแก้ปัญหาคือการสร้างแอพไฮบริดซึ่งจะให้บริการหน้า HTML ทั้งหมดในการโหลดครั้งแรกเช่นเมื่อคุณกด / แคตตาล็อก / รองเท้า สำหรับการนำทางเพิ่มเติมผ่านเว็บไซต์คุณสามารถใช้ ajax เพื่อดึงข้อมูลบล็อกที่จำเป็นเท่านั้น

หนึ่งในวิธีการที่จะสร้างภาพรวมของหน้าของคุณตัวอย่างเช่นโดยใช้PhantomJS นอกจากนี้ยังมีวิธีการชำระเงินบางอย่างเช่น:

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

ฉันสามารถแบ่งปันข้อมูลเชิงลึกเกี่ยวกับการพัฒนาโครงการวีโอไอพีที่ไม่มีหัวเพราะ บริษัท ของฉันได้สร้าง 2 โครงการ

เราได้ตัดสินใจที่จะใช้ reactjs เป็นแอปพลิเคชันส่วนหน้าและเชื่อมต่อกับแบ็กเอนด์ขับเคลื่อนโหนด การเรียก API ไปยังวีโอไอพีนั้นดำเนินการโดยโหนดทางฝั่งเซิร์ฟเวอร์ หมายความว่าไม่มีการโทรไปยังวีโอไอพีที่ส่งจากเบราว์เซอร์

จากมุมมอง API มันดี แต่มีปัญหาบางอย่างที่เราพบระหว่างการพัฒนา Magento2 endpoints บางครั้งมีข้อ จำกัด มาก โดยดีฟอลต์ endpoint handler ไม่อนุญาตให้ส่งข้อมูลเพิ่มเติมไปยังการตอบกลับเนื่องจากไม่ได้ให้extension_attributesแต่ละรายการ ด้วยส่วนหน้าเขียนแยกกันมันไม่ได้เป็นข่าวที่ดี extension_attributesเรามีหลายครั้งที่หันหน้าไปทางจำเป็นต้องเพิ่มข้อมูลบางส่วนและไม่สามารถทำเช่นนี้สำหรับปลายทางวีโอไอพีพื้นเมืองเนื่องจากการขาดการ อินสแตนซ์เหล่านั้นจำเป็นต้องใช้เพื่อแทนที่จุดสิ้นสุดของวีโอไอพีและให้อินเทอร์เฟซของเราเองด้วยฟิลด์เพิ่มเติมหรือสร้างจุดสิ้นสุดที่กำหนดเองของเราเพื่อขยายวีโอไอพีหนึ่งและเปลี่ยนสิ่งที่เราต้องการ

ตัวอย่างเช่นเราจำเป็นต้องแทนที่/rest/V1/categoriesเป็นวีโอไอพีโดยค่าเริ่มต้นไม่ได้เพิ่มเส้นทาง URL ไปที่โครงสร้างหมวดหมู่ /rest/V1/productsซึ่งควรดึงข้อมูลผลิตภัณฑ์นั้น จำกัด เกินไปสำหรับเราเนื่องจากเราจำเป็นต้องใช้เพื่อดูหมวดหมู่และเราต้องการรับตัวกรองที่มีอยู่ในการตอบกลับนั้น

ปัญหาอื่นไม่มีจุดสิ้นสุด เราต้องสร้างสิ่งใหม่สำหรับการส่งอีเมลผู้ติดต่อ breadcrumbs สำหรับหมวดหมู่ดึงข้อมูลใบเสนอราคาจาก quoteId และอีกสองสามอย่างเพื่อจัดการกับองค์ประกอบเฉพาะโครงการ โดยทั่วไปแล้วการพูดที่หน้า Magento2 ปกติคุณจะต้องสร้างบล็อกเพื่อดึงคอลเล็กชันที่กำหนดเองเพื่อจัดการกับคุณอาจต้องเพิ่มจุดปลาย API ของคุณ

ส่วนที่หลอกลวงที่สุดคือชำระเงิน แม้ว่ามันจะถูกเตรียมไว้สำหรับโหมดหัวขาด แต่ก็ยังมีบางส่วนที่จำเป็นต้องปรับเฉพาะ หากคุณใช้ paypal ปกติแล้วคุณจะถูกเปลี่ยนเส้นทางไปยังเว็บไซต์ paypal เพื่อชำระเงินด้วยโทเค็นบางส่วน สำหรับเราโทเค็นนี้จำเป็นต้องดึงข้อมูลแยกต่างหากเนื่องจากเราไม่ทำตามวิธีการเปลี่ยนเส้นทางแบบมาตรฐาน กรณีที่คล้ายกันเกิดขึ้นกับการขอ Adyen ซึ่งจำเป็นต้องเปลี่ยนเส้นทางหลังจากทำการสั่งซื้อ ปลายวีโอไอพีมาตรฐานจะส่งคืนรหัสคำสั่งซื้อตามความสำเร็จเท่านั้นและไม่อนุญาตให้ฉีด URL เปลี่ยนเส้นทาง เรามีปัญหาบางอย่างกับการใช้ 3dSecure

สิ่งสำคัญที่ต้องพิจารณาและทำให้ชัดเจนสำหรับลูกค้าก่อนที่จะหัวขาดคือส่วนที่เกี่ยวข้องทั้งหมดของโมดูลภายนอกจะต้องเขียนใหม่สำหรับการใช้งานเฉพาะของคุณ เนื่องจากในปัจจุบันไม่มีวิธีใดที่โมดูลจะเพิ่มข้อมูลของตัวเองไปยังส่วนที่ไม่มีส่วนหัว สิ่งเดียวที่โมดูลสามารถทำได้คือให้ปลายทาง API

ทั้งหมดในวีโอไอพีหัวขาดเป็นไปได้แน่นอน เราจบลงด้วยการมีโมดูลที่กำหนดเองสำหรับการปรับเปลี่ยนและจุดปลายใหม่ที่สามารถใช้กับโครงการอื่น ๆ

การตอบกลับด้านหน้าทำงานได้ดีมากเนื่องจากการตอบสนองด้านหน้าสามารถแคชหลายสิ่งและแบ็กเอนด์โหนดนั้นเร็วมาก เรากำลังลบเวลาที่จำเป็นสำหรับการดูส่วนหนึ่งของคำขอวีโอไอพีมาตรฐานด้วยวิธีนี้

หากคุณต้องการตรวจสอบว่ามันทำงานอย่างไรที่นี่คือลิงค์ไปยังโครงการ:

https://therake.com/

https://www.emperia.ch/

หากมีคนพูดภาษาดัตช์สามารถตรวจสอบบทความนี้เกี่ยวกับการรับรางวัลได้ด้วย: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[อัปเดต]

อัปเดตเกี่ยวกับคำถามขั้นตอนการชำระเงิน ในขณะที่ฉันเขียนเช็คเอาต์ก็ยุ่งยาก เกตเวย์การชำระเงินในระดับ API นั้นไม่มีอยู่จริง ตัวอย่างเช่นในการชำระเงินปกติเกตเวย์การชำระเงินส่วนใหญ่จะนำคุณไปยังไซต์อื่นเพื่อชำระเงินให้เสร็จ โมดูลเหล่านี้บางส่วนกำลังสร้างคำสั่งซื้อใน magento ในสถานะรอดำเนินการบางส่วน (paypal express) จะเปลี่ยนเส้นทางก่อนที่จะสร้างคำสั่งซื้อ การเปลี่ยนเส้นทางเหล่านั้นมักจะพึ่งพาเซสชันของคุณเพื่อรับรายละเอียดกลับมาหลังจากกลับมา นี่เป็นปัญหาเนื่องจากจุดสิ้นสุดของ orderOrder api ส่งคืน id ของคำสั่งซื้อที่สร้างขึ้นใหม่เท่านั้นไม่ใช่ข้อมูลของการเปลี่ยนเส้นทาง เนื่องจากเรายังไม่ได้กดปุ่มวีโอไอพีโดยตรง แต่โหนดแบ็กเอนด์เซสชันจำเป็นต้องได้รับการเรียกคืนอย่างถูกต้องเมื่อกลับมาจากเกตเวย์ โครงการปัจจุบันของเรามีเกตเวย์ paypal และ Adyen รวมอยู่และใช้เวลามากกว่า 150 ชั่วโมง

นี่คือโครงการโอเพนซอร์สhttps://github.com/ishakhsuvarov/going-headless

พื้นที่เก็บข้อมูลนี้สร้างขึ้นตามการสนทนา "Going Headless" ซึ่งเป็นส่วนหนึ่งของเซสชัน Imagine 2017 DevExchange เพื่อรวบรวมและหารือเกี่ยวกับแนวคิดเกี่ยวกับการใช้งาน Web API ของ Magento ด้วยส่วนหน้าแบบกำหนดเอง เป้าหมายหลักของโครงการนี้คือการรวบรวมจุดที่สำคัญที่สุดและเจ็บปวดที่สุดในการไหลของ Web API และการพัฒนาโซลูชันซึ่งจะตอบสนองกรณีการใช้งานส่วนใหญ่