Magento 2 như một giải pháp không đầu

Tôi muốn biết liệu có một số thực tiễn tốt nhất để sử dụng Magento 2 như một giải pháp thương mại điện tử không đầu .

Một thương mại điện tử điển hình trong năm 2017 là có một giải pháp đa kênh bao gồm

• Thương mại điện tử
• CMS
• Đa nền tảng
• Tích hợp hệ thống cấp (ERP, ...)

Tôi muốn biết làm thế nào liên quan đến API Magento 2 với loại giải pháp này.

Cách tiếp cận của tôi:

• Sử dụng khung giao diện khác (như góc) cho ứng dụng web trên máy tính để bàn / thiết bị di động và ứng dụng di động

• Chỉ sử dụng API Magento 2 để truy xuất hoặc tương tác với dữ liệu / hành động thương mại điện tử

• Chỉ sử dụng API CMS để truy xuất dữ liệu CMS.

Pro: Chỉ API của, omnichannel

Nhược điểm: Giới hạn về hiệu suất / tính năng / định dạng

Một số câu hỏi cho phương pháp này:

• Ai chịu trách nhiệm định dạng dữ liệu, ví dụ giá cả. API Magento và khung frontend?
• Ai chịu trách nhiệm thay đổi kích thước hình ảnh sản phẩm và lưu trữ chúng? Bởi vì trong API Magento 2 gốc không có hệ thống thay đổi kích thước hoặc bộ đệm.
• Tôi có cần tạo API cô lập tùy chỉnh mới hoặc mở rộng nguồn gốc cho mục đích nâng cấp trong tương lai không?
• Bạn có khuyên nên sử dụng một lớp bổ sung để kết hợp API CMS và Magento không?

Tôi đánh giá cao bạn để chia sẻ lợi nhuận của bạn trong kinh nghiệm.

Hơn nữa, tôi tìm thấy cách tiếp cận này: http://fbrnc.net/blog/2015/10/super-scaling-magento

Liên kết hữu ích:

• https://blogi.lamia.fi/verkkokaupat/headless-ec Commerce /
• http://www.magetitans.it/headless-new-buzzword-magento-2-sander-meach/
• https://www.youtube.com/watch?v=6OuzAtqtWRE

• https://pantheon.io/blog/headless-websites-whats-big-deal-decoupling-arch architecture

• http://buytaert.net/the-future-of-decoupling-drupal

• https://creately.com/diagram/example-v2/ihbyjjkf/Example%20Headless%20Arch architecture

• https://www.lullabot.com/articles/should-you-decouple

• https://alankent.me/2016/12/14/headless-magento-and-extensions/

BIÊN TẬP :

Tôi đã tìm thấy một bootstrap tốt để tạo logic bộ nhớ cache của riêng bạn cho API Magento 2 của bạn: https://github.com/magespecialist/m2-MSP_APIEnhancer

EDIT: Một dự án mã nguồn mở tuyệt vời để sử dụng Magento 2 làm thương mại điện tử không đầu với VueJS PWA: https://github.com/Divante Ware / vue-storefront

EDIT: Các công cụ PWA Magento 2 chính thức dựa trên React: https://github.com/magento-research/pwa-studio

Trả lời các câu hỏi

Ai chịu trách nhiệm định dạng dữ liệu, ví dụ giá cả. API Magento và khung frontend?

API Magento cung cấp quyền truy cập vào dữ liệu và logic kinh doanh . Định dạng dữ liệu / giá là một phần của logic trình bày , vì vậy theo cách này, bạn có thể linh hoạt hơn để trình bày thông tin theo cách bạn muốn (mà không bị buộc phải thực hiện theo cách Magento).

Ví dụ: bạn có thể sử dụng javascript để phát hiện cài đặt ngôn ngữ và cung cấp dữ liệu phù hợp. Kiểm tra sau: navigator.l Language toLocaleString ()

Hoặc, bạn thậm chí có thể chọn nhập giá từ Magento sang hệ thống bên thứ 3 hoặc công cụ phân tích dữ liệu và việc định giá theo định dạng tiền tệ sẽ chỉ phá vỡ quy trình nhập cho đến khi bạn giải quyết "chuyển đổi tiền tệ".

Ai chịu trách nhiệm thay đổi kích thước hình ảnh sản phẩm và lưu trữ chúng? Bởi vì trong API Magento 2 gốc không có hệ thống thay đổi kích thước hoặc bộ đệm.

Chính xác. Như tôi đã nói ở trên, Magento cung cấp quyền truy cập vào dữ liệu (không có logic trình bày). Tùy bạn sử dụng nó như thế nào.

Ví dụ: bạn có thể chọn thay đổi kích thước hình ảnh thích ứng http://adaptive-images.com/details.htm , để bạn có thể dễ dàng sử dụng hình ảnh gốc và làm bất cứ điều gì bạn muốn.

Bạn có thể chọn cách bạn sẽ lưu trữ hình ảnh, bạn muốn sử dụng tính năng nén mất dữ liệu hoặc không mất dữ liệu để giảm hình ảnh, v.v.

Tôi có cần tạo API cô lập tùy chỉnh mới hoặc mở rộng nguồn gốc cho mục đích nâng cấp trong tương lai không?

Tôi khuyên bạn nên tạo API sẽ được sử dụng cho logic trình bày và bạn sẽ chắc chắn 99,9% (theo phỏng đoán của tôi) rằng bạn sẽ không bị ảnh hưởng bởi bản nâng cấp API Magento2 trong tương lai.

Bạn có khuyên nên sử dụng một lớp bổ sung để kết hợp API CMS và Magento không?

Rat khuyen khich. Nhưng, lớp bổ sung không phải là một ứng dụng bổ sung; nó có thể là một mô-đun Magento2. Điều tốt về điều này là thực tế là bạn có thể tự do kết hợp nó theo cách bạn muốn; bạn có thể xây dựng lớp proxy của mình bằng bất kỳ ngôn ngữ / công nghệ nào bạn muốn.

Tôi đánh giá cao bạn để chia sẻ lợi nhuận của bạn trong kinh nghiệm.

Có nhiều cách tiếp cận bạn có thể sử dụng ở đây. Tôi sẽ chia sẻ ý kiến ​​của tôi về nó.

Cách tiếp cận của tôi không đầu

Đầu tiên, tôi sẽ chia nó thành hai lớp: lớp proxy và lớp trình bày .

Lớp proxy

Điều đầu tiên bạn sẽ phải xem xét là về việc xây dựng lớp Proxy. Đằng sau, bạn có thể sử dụng Magento API, CMS API, ERP API, x API, bất cứ điều gì bạn muốn ...

Trong lớp proxy, bạn có thể tự do sử dụng và sắp xếp dữ liệu theo cách bạn muốn. Bạn có thể triển khai lớp bộ đệm ở đó, cũng như các chức năng bổ sung để định dạng dữ liệu, theo dõi khách hàng, tự động hóa khác nhau, v.v. Nói chung, bất cứ điều gì bạn cần để dễ dàng tung hứng trong lớp trình bày.

Lớp proxy không cần phải được mã hóa bằng PHP; nó có thể được mã hóa bằng Java, NodeJS hoặc thậm chí bạn có thể sử dụng AWS API Gateway, AWS SQS và Lambda để cung cấp toàn bộ lớp proxy hoặc chỉ là một phần của nó.

Một trong những cách tiếp cận bạn có thể sử dụng được mô tả bởi Fabrizio Branca tại http://fbrnc.net/blog/2015/10/super-scaling-magento

Lớp trình bày

Lớp trình bày phụ thuộc vào nền tảng máy khách; nếu bạn sẽ sử dụng nó cho Ứng dụng di động, mọi thứ khá rõ ràng về cách bạn nên sử dụng API proxy.

Đối với một ứng dụng web, có rất nhiều khả năng. Bạn có thể dùng:

• Giải pháp PHP tiêu chuẩn (được cung cấp bởi bất kỳ khung công tác nào) trong đó bạn có thể sử dụng bất kỳ công cụ tạo khuôn mẫu PHP nào (như Smarty, Twig, Dwoo ...) để cung cấp đầu ra HTML
• Java / NodeJS / bất kỳ ngôn ngữ nào bạn cảm thấy quen thuộc
• Giải pháp hoàn toàn dựa trên javascript, sẽ kết xuất tất cả HTML và sẽ gọi các API phù hợp thông qua ajax để điền dữ liệu vào đó
• Bất kỳ kết hợp / kết hợp của những cách tiếp cận từ trên

Đây không phải là bởi cuốn sách danh sách, tôi vừa chia sẻ vài kết hợp. Trong thực tế, trí tưởng tượng của bạn là giới hạn duy nhất.

Suy nghĩ cuối cùng

Sử dụng giải pháp dựa trên javascript càng nhiều càng tốt, vì nó có thể cung cấp trải nghiệm tốt hơn cho Khách hàng, tải trọng nhỏ hơn cho tải trang, thậm chí bạn có thể tải dữ liệu đầu cơ nếu bạn có thể dự đoán các hành động tiếp theo của khách hàng.

NHƯNG, vấn đề với giải pháp javascript hoàn toàn là SEO. Nếu tất cả dữ liệu của bạn được tải thông qua Ajax, Google có thể sẽ không thể phân tích cú pháp.

Giải pháp là tạo một ứng dụng lai sẽ phục vụ toàn bộ trang HTML trong lần tải đầu tiên, ví dụ như khi bạn nhấn / catalog / giày. Đối với bất kỳ điều hướng nào khác thông qua trang web, bạn có thể sử dụng ajax để chỉ tìm nạp các khối cần thiết.

Một trong những cách tiếp cận sẽ là tạo ảnh chụp nhanh trang của bạn, ví dụ như bằng cách sử dụng PhantomJS . Cũng có một vài giải pháp trả phí cho việc này, như:

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

Tôi có thể chia sẻ một số hiểu biết về việc phát triển các dự án magento không đầu vì công ty của tôi đã tạo ra 2 trong số đó.

Chúng tôi đã quyết định sử dụng Reacjs như một ứng dụng lối vào và kết nối nó với phụ trợ được hỗ trợ nút. Các lệnh gọi API đến magento được thực hiện bởi nút ở phía máy chủ. Điều này có nghĩa là không có cuộc gọi đến magento được gửi từ trình duyệt.

Từ quan điểm API, nó là tốt nhưng có một số vấn đề mà chúng tôi đã gặp trong quá trình phát triển. Điểm cuối Magento2 đôi khi rất hạn chế. Theo mặc định, trình xử lý điểm cuối không cho phép đưa dữ liệu bổ sung vào phản hồi vì chúng không được cung cấp extension_attributescho mỗi người. Với frontend được viết riêng nó không phải là một tin tốt. Chúng tôi đã nhiều lần phải đối mặt với nhu cầu thêm một số dữ liệu và không thể làm điều này cho điểm cuối magento bản địa do thiếu extension_attributes. Những trường hợp được yêu cầu như ghi đè điểm cuối magento và cung cấp giao diện riêng của chúng tôi với các trường bổ sung hoặc tạo điểm cuối tùy chỉnh của chúng tôi mở rộng magento và thay đổi những gì chúng tôi cần.

Ví dụ: chúng tôi cần ghi đè /rest/V1/categoriesdưới dạng magento theo mặc định không thêm đường dẫn url vào cây danh mục. /rest/V1/productsviệc tải dữ liệu sản phẩm cũng quá hạn chế đối với chúng tôi vì chúng tôi cần sử dụng nó cho chế độ xem danh mục và chúng tôi muốn nhận các bộ lọc có sẵn trong phản hồi đó.

Một vấn đề khác là thiếu điểm cuối. Chúng tôi đã phải tạo một cái để gửi email liên hệ, mẩu bánh mì cho danh mục, tìm nạp dữ liệu trích dẫn từ quoteId và một vài bổ sung để xử lý các yếu tố cụ thể của dự án. Nói chung, ở đâu trong Magento2 bình thường, bạn sẽ tạo một khối tìm nạp một số bộ sưu tập tùy chỉnh để đối phó với bạn có thể cần thêm điểm cuối api của bạn.

Phần lừa nhất là thanh toán. Mặc dù nó được chuẩn bị cho chế độ không đầu, nhưng vẫn có một số phần cần điều chỉnh cụ thể. Nếu bạn đang sử dụng paypal thì thông thường bạn sẽ được chuyển hướng đến trang paypal để thanh toán với một số tobest. Đối với chúng tôi, mã thông báo này cần được tìm nạp riêng vì chúng tôi không tuân theo cách chuyển hướng tiêu chuẩn. Trường hợp tương tự là nối Adyen cần chuyển hướng sau khi đặt hàng. Điểm cuối magento tiêu chuẩn chỉ trả về id đơn hàng khi thành công và không cho phép tiêm url chuyển hướng. Chúng tôi cũng có một số vấn đề với việc triển khai 3dSecure.

Một điều quan trọng cần xem xét và làm rõ cho khách hàng trước khi đi đầu là tất cả các phần liên quan đến frontend của các mô-đun bên ngoài sẽ cần phải được viết lại để thực hiện cụ thể của bạn. Vì hiện tại không có cách nào để một mô-đun thêm dữ liệu của chính nó vào bất kỳ phần không đầu nào. Điều duy nhất mà mô-đun có thể làm là cung cấp các điểm cuối API.

Tất cả trong tất cả magento không đầu là chắc chắn có thể. Chúng tôi cuối cùng đã có mô-đun tùy chỉnh cho những điều chỉnh và điểm cuối mới có thể được sử dụng với các dự án khác.

React front hoạt động rất tốt cũng như phản ứng phía trước có thể lưu trữ rất nhiều thứ và nút phụ trợ cực kỳ nhanh. Chúng tôi đang loại bỏ thời gian cần thiết để xem một phần yêu cầu magento tiêu chuẩn theo cách này.

Nếu bạn muốn kiểm tra xem nó hoạt động như thế nào thì đây là các liên kết đến các dự án:

https://therake.com/

https://www.emperia.ch/

Nếu ai đó nói tiếng Hà Lan cũng có thể kiểm tra bài viết này về liệu pháp: http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-c Commerce

[CẬP NHẬT]

Cập nhật liên quan đến câu hỏi kiểm tra dòng chảy. Như tôi đã viết thanh toán là khó khăn. Cổng thanh toán ở cấp độ api về cơ bản là không tồn tại. Ví dụ: trong thanh toán thường xuyên, hầu hết các cổng thanh toán đều chuyển hướng bạn đến trang web khác để hoàn tất thanh toán. Một số mô-đun đang tạo đơn hàng trong magento ở trạng thái chờ xử lý, một số (paypal express) thực hiện chuyển hướng trước khi đơn hàng được tạo. Những người chuyển hướng thường dựa vào phiên của bạn để lấy lại thông tin chi tiết sau khi trở về. Đây là một vấn đề vì điểm cuối api của PlaceOrder chỉ trả về id của đơn hàng mới được tạo và không phải là thông tin của chuyển hướng. Vì chúng tôi cũng đã nhấn không phải magento trực tiếp mà là phụ trợ nút, phiên cần phải được khôi phục đúng cách khi trở về từ cổng. Các dự án hiện tại của chúng tôi đã tích hợp cổng paypal và Adyen và chúng tôi đã mất hơn 150 giờ.

Đây là dự án nguồn mở https://github.com/ishakhsuvarov/ gửi-headless

Kho lưu trữ này được tạo cho mỗi cuộc thảo luận "Đi không đầu", là một phần của các phiên DevExchange của Imagine 2017, để thu thập và thảo luận về các ý tưởng liên quan đến việc sử dụng API Web của Magento với lối vào tùy chỉnh. Mục tiêu chính của dự án này là thu thập những điểm quan trọng và đau đớn nhất trong các luồng API Web và phát triển một giải pháp, đáp ứng hầu hết các trường hợp sử dụng.