헤드리스 솔루션 인 Magento 2

Magento 2를 헤드리스 전자 상거래 솔루션으로 사용 하는 모범 사례 가 있는지 알고 싶습니다 .

2017 년의 전형적인 전자 상거래는 다음을 포함하는 옴니 채널 솔루션을 갖추는 것입니다.

• 전자 상거래
• CMS
• 멀티 플랫폼
• 계층 시스템 통합 (ERP, ...)

이런 종류의 솔루션에 Magento 2 API가 어떻게 관여하는지 알고 싶습니다.

내 접근 방식 :

• 데스크톱 / 모바일 웹앱 및 모바일 앱에 다른 프론트 엔드 프레임 워크 (예 : 각도)를 사용하십시오.

• 전자 상거래 데이터 / 액션을 검색하거나 상호 작용하려면 Magento 2 API 만 사용하십시오.

• CMS 데이터를 검색하려면 CMS API 만 사용하십시오.

프로 : API 만, 옴니 채널

단점 : 성능 / 기능 / 포맷 제한

이 접근법에 대한 몇 가지 질문 :

• 가격 등의 데이터 형식을 책임지는 사람 마 젠토 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%20 건축

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

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

편집하다 :

Magento 2 API에 대한 자체 캐시 논리를 만들기 위해 좋은 부트 스트랩을 찾았습니다 : https://github.com/magespecialist/m2-MSP_APIEnhancer

편집 : VueJS PWA에서 Magento 2를 헤드리스 전자 상거래로 사용하기위한 훌륭한 오픈 소스 프로젝트 : https://github.com/DivanteLtd/vue-storefront

편집 : React 기반의 공식 Magento 2 PWA 도구 : https://github.com/magento-research/pwa-studio

질문에 대한 답변

가격 등의 데이터 형식을 책임지는 사람 마 젠토 API와 프론트 엔드 프레임 워크?

Magento API는 데이터 및 비즈니스 로직에 대한 액세스를 제공합니다 . 데이터 / 가격 형식화는 프리젠 테이션 로직의 일부 이므로, 이런 방식으로 원하는 방식으로 정보를 제공 할 수있는 유연성이 더욱 향상됩니다 (Magento 방식으로 정보를 강제하지 않고도).

예를 들어, 자바 스크립트를 사용하여 로캘 설정을 감지하고 적절한 데이터를 제공 할 수 있습니다. 다음을 확인하십시오. navigator.language toLocaleString ()

또는 Magento에서 타사 시스템 또는 데이터 분석 도구로 가격을 가져 오도록 선택할 수 있으며 통화 형식에 따라 가격이 지정된 가격을 지정하면 "통화 변환"을 해결할 때까지만 가져 오기 프로세스가 중단됩니다.

제품 이미지의 크기를 조정하고 캐시하는 담당자는 누구입니까? 기본 Magento 2 API에는 크기 조정 또는 캐시 시스템이 없기 때문입니다.

바로 그거죠. 위에서 말했듯이 Magento는 프레젠테이션 로직없이 데이터에 대한 액세스를 제공합니다. 당신이 그것을 어떻게 사용할지는 당신에게 달려 있습니다.

예를 들어 적응 형 이미지 크기 조정 http://adaptive-images.com/details.htm을 선택 하여 원본 이미지를 쉽게 사용하고 원하는 작업을 수행 할 수 있습니다.

이미지를 캐시하는 방법을 선택할 수 있으며 이미지를 줄이기 위해 손실 또는 무손실 압축을 사용하고 싶을 수 있습니다.

향후 업그레이드 목적으로 새 사용자 지정 격리 API를 생성하거나 기본 확장을 사용해야합니까?

프리젠 테이션 로직에 사용될 API를 만들 것을 권장하며, 향후 Magento2 API 업그레이드의 영향을받지 않을 것이라고 99.9 %가 될 것입니다.

CMS와 Magento API를 결합하기 위해 추가 계층을 사용하도록 권장합니까?

추천. 그러나 추가 계층은 추가 응용 프로그램 일 필요는 없습니다. Magento2 모듈 일 수도 있습니다. 이것에 대한 좋은 점은 원하는대로 자유롭게 조합 할 수 있다는 사실입니다. 원하는 언어 / 기술을 사용하여 프록시 계층을 구축 할 수 있습니다.

당신의 경험에 귀를 기울여 주셔서 감사합니다.

여기에 사용할 수있는 방법이 많이 있습니다. 그것에 대한 의견 을 나누 겠습니다 .

헤드리스에 대한 나의 접근

먼저 프록시 레이어 와 프리젠 테이션 레이어의 두 레이어로 나누겠습니다 .

프록시 계층

가장 먼저 고려해야 할 것은 프록시 계층을 만드는 것입니다. 배후에서 Magento API, CMS API, ERP API, x API 등 원하는 것을 활용할 수 있습니다.

프록시 계층에서는 원하는 방식으로 데이터를 자유롭게 사용하고 구성 할 수 있습니다. 여기에서 캐싱 계층과 데이터 형식, 고객 추적, 다양한 자동화 등을위한 추가 기능을 구현할 수 있습니다. 일반적으로 프레젠테이션 계층에서 쉽게 전환하기 위해 필요한 모든 것을 제공합니다.

프록시 레이어는 PHP로 코딩 할 필요가 없습니다. Java, NodeJS로 코딩하거나 AWS API Gateway, AWS SQS 및 Lambda를 사용하여 전체 프록시 계층을 제공하거나 그 일부만 제공 할 수도 있습니다.

사용 가능한 접근 방법 중 하나는 Fabrizio Branca ( http://fbrnc.net/blog/2015/10/super-scaling-magento) 에서 설명합니다.

프리젠 테이션 레이어

프리젠 테이션 레이어는 클라이언트 플랫폼에 따라 다릅니다. 모바일 앱에 사용하려는 경우 프록시 API를 활용하는 방법에 대해 명확하게 알 수 있습니다.

웹 애플리케이션의 경우 많은 가능성이 있습니다. 당신이 사용할 수있는:

• 모든 PHP 템플릿 엔진 (Smarty, Twig, Dwoo ... 등)을 사용하여 HTML 출력을 제공 할 수있는 표준 PHP 솔루션 (모든 프레임 워크 기반)
• Java / NodeJS / 친숙한 언어
• 순수하게 자바 스크립트 기반 솔루션으로, 모든 HTML을 렌더링하고 ajax를 통해 적절한 API를 호출하여 데이터로 채 웁니다.
• 위의 접근 방식의 모든 하이브리드 / 조합

이것은 책 목록에 의한 것이 아니며 몇 가지 조합을 공유했습니다. 실제로, 당신의 상상력이 유일한 한계입니다.

마지막 생각들

Javascript 기반 솔루션을 최대한 많이 사용하십시오. 고객에게 더 나은 경험을 제공하고 페이지로드에 대한 페이로드를 줄이며 고객의 다음 조치를 예측할 수있을 경우 추론 적 데이터로드를 수행 할 수도 있습니다.

그러나 순수한 자바 스크립트 솔루션의 문제는 SEO입니다. 모든 데이터가 Ajax를 통해로드되는 경우 Google에서 해당 데이터를 구문 분석 할 수 없습니다.

해결책은 예를 들어 / catalog / shoes를 눌렀을 때 첫 번째로드에서 전체 HTML 페이지를 제공하는 하이브리드 앱을 만드는 것입니다. 사이트를 통한 추가 탐색을 위해 ajax를 사용하여 필요한 블록 만 가져올 수 있습니다.

접근 방식 중 하나는 예를 들어 PhantomJS 를 사용하여 페이지의 스냅 샷을 작성하는 것 입니다. 이와 같은 유료 솔루션은 다음과 같습니다.

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

회사에서 2 개의 프로젝트를 만들면서 헤드리스 마 젠토 프로젝트 개발에 대한 통찰력을 공유 할 수 있습니다.

우리는 reactjs를 프론트 엔드 애플리케이션으로 사용하고이를 노드 구동 백엔드와 연결하기로 결정했습니다. 서버 측 노드에서 magento에 대한 API 호출을 수행했습니다. 이는 브라우저에서 magento에 대한 호출이 전송되지 않았 음을 의미합니다.

API 관점에서 보면 좋지만 개발 중에 우리가 만난 몇 가지 문제가 있습니다. Magento2 엔드 포인트는 때때로 매우 제한적입니다. 기본적으로 엔드 포인트 핸들러는 추가 데이터를 제공하지 않으므로 응답에 추가 데이터를 삽입 할 수 없습니다 extension_attributes. 프론트 엔드를 별도로 작성하면 좋은 소식이 아닙니다. 우리는 여러 번 데이터를 추가해야 할 필요성에 직면 해 있었으며의 부족으로 인해 네이티브 마 젠토 엔드 포인트에 대해서는이를 수행 할 수 없었습니다 extension_attributes. magento 엔드 포인트를 대체하고 추가 필드가있는 자체 인터페이스를 제공하거나 magento를 확장하고 필요한 것을 변경하는 사용자 정의 엔드 포인트를 작성하는 데 필요한 인스턴스입니다.

예를 들어 /rest/V1/categories기본적으로 magento 로 재정의 해야했지만 카테고리 트리에 URL 경로를 추가하지 않았습니다. /rest/V1/products제품 데이터를 가져와야하는 카테고리도 카테고리보기에 사용해야하므로 해당 응답에서 사용 가능한 필터를 받고 싶었습니다.

또 다른 문제는 엔드 포인트가 누락되었습니다. 우리는 연락처 이메일, 카테고리의 빵 부스러기, quoteId에서 견적 데이터를 가져오고 프로젝트 특정 요소를 처리하기 위해 추가로 하나를 만들어야했습니다. 일반적으로 일반적인 Magento2 프론트에서 사용자 지정 컬렉션을 가져 오는 블록을 생성하면 api 끝점을 추가해야 할 수도 있습니다.

가장 까다로운 부분은 체크 아웃이었습니다. 헤드리스 모드 용으로 준비되었지만 특정 조정이 필요한 일부 부품이 여전히 있습니다. 페이팔을 사용하는 경우 일반적으로 일부 토큰으로 지불하기 위해 페이팔 사이트로 리디렉션됩니다. 우리에게는 표준 리디렉션 방식을 따르지 않으므로이 토큰을 별도로 가져와야합니다. 비슷한 경우는 Adyen을 연결하는 것으로 주문을 한 후 리디렉션이 필요했습니다. 표준 마 젠토 엔드 포인트는 성공시 주문 ID 만 반환하며 리디렉션 URL을 삽입 할 수 없습니다. 3dSecure 구현에 문제가있었습니다.

헤드리스가되기 전에 고객이 고려해야 할 중요한 사항 중 하나는 특정 구현을 위해 외부 모듈의 모든 프런트 엔드 관련 부분을 다시 작성해야한다는 것입니다. 현재로서는 모듈이 헤드리스 부품에 자체 데이터를 추가 할 수있는 방법이 없습니다. 모듈이 수행 할 수있는 유일한 것은 API 엔드 포인트를 제공하는 것입니다.

헤드리스 마 젠토는 모두 가능합니다. 우리는 다른 프로젝트와 함께 사용할 수있는 조정 및 새로운 엔드 포인트를위한 맞춤형 모듈을 갖게되었습니다.

React front는 React front가 많은 것을 캐시 할 수 있고 노드 백엔드가 매우 빠르므로 매우 잘 작동합니다. 이 방법으로 표준 마 젠토 요청의 일부를 보는 데 필요한 시간을 제거하고 있습니다.

작동 방식을 확인하려면 여기에 프로젝트 링크가 있습니다.

https://therake.com/

https://www.emperia.ch/

누군가 네덜란드어를 구사하는 경우이 치료법에 대한이 기사를 확인할 수 있습니다. http://www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[최신 정보]

결제 흐름 질문 관련 업데이트 내가 쓴대로 체크 아웃 까다로운했다. API 레벨의 결제 게이트웨이는 기본적으로 존재하지 않습니다. 예를 들어 정기 결제시 대부분의 결제 게이트웨이는 결제를 완료하기 위해 다른 사이트로 리디렉션합니다. 이러한 모듈 중 일부는 보류 상태의 마 젠토에서 주문을 생성하고 있으며 일부 (페이팔 익스프레스)는 주문이 생성되기 전에 리디렉션됩니다. 이러한 리디렉션은 종종 세션을 사용하여 돌아온 후 세부 정보를 가져옵니다. placeOrder api 엔드 포인트는 새로 작성된 주문의 ID 만 리턴하고 경로 재 지정 정보는 리턴하지 않으므로 문제점입니다. 우리는 또한 magento가 아닌 노드 백엔드에 직접 도달했기 때문에 게이트웨이에서 돌아올 때 세션을 올바르게 복원해야합니다. 현재 프로젝트에 페이팔과 Adyen 게이트웨이가 통합되어 150 시간 이상 걸렸습니다.

다음은 오픈 소스 프로젝트입니다 https://github.com/ishakhsuvarov/going-headless

이 저장소는 Imagine 2017 DevExchange 세션의 일부인 토론 "Going Headless"마다 사용자 정의 프론트 엔드에서 Magento의 Web API 사용에 관한 아이디어를 수집하고 토론합니다. 이 프로젝트의 주요 목표는 웹 API 흐름 및 솔루션 개발에서 가장 중요하고 고통스러운 점을 수집하여 대부분의 사용 사례를 충족시키는 것입니다.