ヘッドレスソリューションとしてのMagento 2

Magento 2をヘッドレスEコマースソリューションとして使用するためのベストプラクティスがあるかどうかを知りたい。

2017年の典型的なEコマースは、以下を含むオムニチャネルソリューションを持つことです。

• Eコマース
• CMS
• マルチプラットフォーム
• 階層システム統合（ERP、...）

この種のソリューションにMagento 2 APIがどのように関与するかを知りたいです。

私のアプローチ：

• デスクトップ/モバイルWebアプリとモバイルアプリに別のフロントエンドフレームワーク（角度など）を使用する

• Eコマースのデータ/アクションを取得または操作するには、Magento 2 APIのみを使用してください

• CMSデータを取得するには、CMS APIのみを使用してください。

プロ： APIのみ、オムニチャネル

短所：パフォーマンス/機能/フォーマットの制限

このアプローチに関するいくつかの質問：

• 価格などのデータのフォーマットを担当するのは誰ですか。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/

編集：

Magento 2 APIの独自のキャッシュロジックを作成するための優れたブートストラップを見つけました：https : //github.com/magespecialist/m2-MSP_APIEnhancer

編集： Magento 2をVueJS PWAでヘッドレスEコマースとして使用するための素晴らしいオープンソースプロジェクト：https : //github.com/DivanteLtd/vue-storefront

編集： Reactに基づく公式Magento 2 PWAツール：https : //github.com/magento-research/pwa-studio

質問への回答

価格などのデータのフォーマットを担当するのは誰ですか。Magento APIとフロントエンドフレームワーク？

Magento APIは、データおよびビジネスロジックへのアクセスを提供します。データ/価格のフォーマットはプレゼンテーションロジックの一部であるため、このようにすると、Magentoの方法で強制することなく、希望する方法で情報を表示する柔軟性が高まります。

たとえば、javascriptを使用してロケール設定を検出し、適切なデータを提供できます。以下を確認してください： navigator.language toLocaleString（）

または、Magentoからサードパーティシステム、またはデータ分析ツールに価格をインポートすることもできます。通貨形式に従ってフォーマットされた価格は、「通貨変換」を解決するまでインポートプロセスを中断します。

製品画像のサイズ変更とキャッシュを担当するのは誰ですか？ネイティブMagento 2 APIには、サイズ変更またはキャッシュシステムがないためです。

まさに。上で述べたように、Magentoはデータへのアクセスを提供します（プレゼンテーションロジックなし）。どのように使用するかはあなた次第です。

たとえば、アダプティブイメージのサイズ変更http://adaptive-images.com/details.htmを選択すると、元のイメージを簡単に使用して、必要な操作を実行できます。

画像をキャッシュする方法を選択したり、画像を縮小するために非可逆または可逆圧縮を使用したりできます。

将来のアップグレードのために、新しいカスタム分離APIを作成するか、ネイティブを拡張する必要がありますか？

プレゼンテーションロジックに使用されるAPIを作成することをお勧めします。Magento2APIの将来のアップグレードの影響を受けないことを99.9％（私の推測）確信しています。

CMSとMagento APIを組み合わせるために追加のレイヤーを使用することをお勧めしますか？

強くお勧めします。ただし、追加のレイヤーは追加のアプリケーションである必要はありません。Magento2モジュールにすることもできます。これの良いところは、あなたが自由に組み合わせることができるという事実です。必要な言語/技術を使用してプロキシ層を構築できます。

経験を積んでいただければ幸いです。

ここで使用できる多くのアプローチがあります。私の意見を共有します。

ヘッドレスへの私のアプローチ

まず、プロキシレイヤーとプレゼンテーションレイヤーの 2つのレイヤーに分割します。

プロキシ層

最初に考慮する必要があるのは、プロキシレイヤーの構築です。舞台裏では、Magento API、CMS API、ERP API、x APIなど、何でも使用できます...

プロキシ層では、自由にデータを自由に使用および整理できます。そこにキャッシングレイヤー、およびデータの書式設定、顧客追跡、さまざまな自動化などの追加機能を実装できます。一般に、プレゼンテーションレイヤーで簡単にジャグリングするために必要なものはすべて。

プロキシ層はPHPでコーディングする必要はありません。Java、NodeJSでコーディングすることも、AWS API Gateway、AWS SQS、Lambdaを使用してプロキシレイヤー全体またはその一部のみを提供することもできます。

使用できるアプローチの1つは、ファブリツィオブランカによってhttp://fbrnc.net/blog/2015/10/super-scaling-magentoで説明されています。

プレゼンテーション層

プレゼンテーション層はクライアントプラットフォームに依存します。Mobile Appで使用する場合、プロキシAPIの使用方法については明確です。

Webアプリケーションの場合、多くの可能性があります。次を使用できます。

• PHPテンプレートエンジン（Smarty、Twig、Dwoo ...など）を使用してHTML出力を提供できる標準のPHPソリューション（任意のフレームワークを使用）
• Java / NodeJS /おなじみの言語
• すべてのHTMLをレンダリングし、ajaxを介して適切なAPIを呼び出してデータを入力する、純粋にJavaScriptベースのソリューション
• 上記のアプローチのハイブリッド/組み合わせ

これは書籍リストによるものではなく、いくつかの組み合わせを共有しただけです。現実には、あなたの想像力が唯一の制限です。

最終的な考え

JavaScriptベースのソリューションをできる限り使用します。顧客に優れたエクスペリエンスを提供し、ページ読み込みのペイロードを小さくできるため、顧客の次のアクションを予測できる場合は投機的なデータ読み込みも実行できます。

しかし、純粋にjavascriptソリューションの問題はSEOです。すべてのデータがAjaxを介してロードされる場合、Googleはおそらくそれを解析できません。

解決策は、たとえば/ catalog / shoesにアクセスしたときなど、最初の読み込み時にHTMLページ全体を提供するハイブリッドアプリを作成することです。サイトをさらにナビゲートするには、ajaxを使用して必要なブロックのみを取得できます。

アプローチの1つは、たとえばPhantomJSを使用して、ページのスナップショットを作成することです。次のような有料ソリューションもいくつかあります。

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

私の会社が2つのプロジェクトを作成したため、ヘッドレスmagentoプロジェクトの開発に関する洞察を共有できます。

reactjsをフロントエンドアプリケーションとして使用し、ノード駆動のバックエンドに接続することにしました。magentoへのAPI呼び出しは、サーバー側のノードによって実行されました。つまり、magentoへの呼び出しはブラウザから送信されませんでした。

APIの観点からは良いことですが、開発中に遭遇したいくつかの問題があります。Magento2エンドポイントは非常に限られている場合があります。デフォルトでは、エンドポイントハンドラーは応答に追加データを注入することを許可していませんextension_attributes。これらは各データに提供されないためです。フロントエンドが個別に記述されているため、これは朗報ではありません。私たちは何度もデータを追加する必要に直面しており、ネイティブmagentoエンドポイントではが不足しているためこれを行うことができませんでしたextension_attributes。これらのインスタンスは、magentoエンドポイントをオーバーライドして独自のインターフェイスに追加フィールドを提供するか、magentoエンドポイントを拡張して必要なものを変更するカスタムエンドポイントを作成する必要がありました。

たとえば/rest/V1/categories、magentoはデフォルトでカテゴリツリーにURLパスを追加しなかったため、オーバーライドする必要がありました。/rest/V1/products商品データを取得する必要もありましたが、カテゴリビューに使用する必要があり、そのレスポンスで利用可能なフィルターを受信したかったため、商品データを取得する必要がありました。

別の問題は、エンドポイントの欠落でした。連絡先メールの送信、カテゴリのブレッドクラム、quoteIdからの見積データのフェッチ、およびプロジェクト固有の要素を処理するための追加データを作成する必要がありました。一般的に言えば、通常のMagento2フロントでは、カスタムコレクションを取得するブロックを作成して、APIエンドポイントを追加する必要がある場合があります。

最も重要な部分はチェックアウトでした。ヘッドレスモード用に準備されていますが、特定の調整が必要な部分がまだあります。PayPalを使用している場合、通常は一部のトークンでの支払いのためにPayPalサイトにリダイレクトされます。私たちにとって、このトークンは標準のリダイレクト方法に従っていないため、個別に取得する必要があります。同様のケースは、注文後にリダイレクトが必要なAdyenを接続した場合です。標準のmagentoエンドポイントは、成功時にのみ注文IDを返し、リダイレクトURLの挿入を許可しません。3dSecureの実装にも問題がありました。

ヘッドレスになる前に考慮し、顧客に明確にするべき重要なことの1つは、外部モジュールのすべてのフロントエンド関連部分を特定の実装のために書き換える必要があることです。現在のところ、モジュールが独自のデータをヘッドレスパーツに追加する方法はありません。モジュールでできることは、APIエンドポイントを提供することだけです。

すべてのすべてのヘッドレスmagentoは間違いなく可能です。最終的に、これらの調整用のカスタムモジュールと、他のプロジェクトで使用できる新しいエンドポイントが用意されました。

反応フロントは非常にうまく機能し、反応フロントは多くのものをキャッシュでき、ノードバックエンドは非常に高速です。この方法で、標準のmagentoリクエストの表示部分に必要な時間を削除しています。

動作を確認したい場合は、プロジェクトへのリンクをご覧ください。

https://therake.com/

https://www.emperia.ch/

誰かがオランダ語を話す場合、therakeについての次の記事もチェックできます：http : //www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[更新]

チェックアウトフローの質問に関する更新。私が書いたように、チェックアウトはトリッキーでした。APIレベルの支払いゲートウェイは基本的に存在しません。たとえば、通常のチェックアウトでは、ほとんどの支払いゲートウェイが支払いを完了するために別のサイトにリダイレクトします。それらのモジュールの一部は保留状態のmagentoで注文を作成していますが、一部（paypal express）は注文が作成される前にリダイレクトします。これらのリダイレクトは、多くの場合、帰国後に詳細を取得するためにセッションに依存します。placeOrder APIエンドポイントは、新しく作成された注文のIDのみを返し、リダイレクトの情報は返さないため、これは問題でした。また、magentoではなくノードバックエンドを直接ヒットするため、ゲートウェイから戻るときにセッションを適切に復元する必要があります。現在のプロジェクトでは、PayPalとAdyenのゲートウェイが統合されており、150時間以上かかりました。

こちらがオープンソースプロジェクトですhttps://github.com/ishakhsuvarov/going-headless

このリポジトリは、Imagine 2017 DevExchangeセッションの一部であったディスカッション「Going Headless」ごとに作成され、カスタムフロントエンドでのMagentoのWeb APIの使用に関するアイデアを収集して議論します。このプロジェクトの主な目標は、Web APIフローの最も重要で苦痛なポイントを収集し、ほとんどのユースケースを満たすソリューションを開発することです。