Magento 2无头解决方案

我想知道是否有一些最佳实践将Magento 2用作无头电子商务解决方案。

2017年典型的电子商务是拥有全渠道解决方案，其中包括

• 电子商务
• 不育系
• 多平台
• 层系统集成（ERP，...）

我想知道如何将Magento 2 API与这种解决方案结合在一起。

我的方法：

• 对台式机/移动Web应用程序和移动应用程序使用不同的前端框架（例如angular）

• 仅使用Magento 2 API才能检索电子商务数据/操作或与之交互

• 仅使用CMS API才能检索CMS数据。

专业版：仅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的无头电子商务：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导入到3rd party系统或数据分析工具，并且按照货币格式对价格进行格式化只会破坏导入过程，直到您解决“货币转换”。

谁负责调整产品图像的大小并缓存它们？因为在本地Magento 2 API中没有调整大小或缓存系统。

究竟。如前所述，Magento提供了对数据的访问（没有表示逻辑）。如何使用它取决于您。

例如，您可以选择自适应图像调整大小http://adaptive-images.com/details.htm，以便您可以轻松使用原始图像并做任何您想做的事情。

您可以选择缓存图像的方式，是否要使用有损或无损压缩来缩小图像等。

我是否需要创建新的自定义隔离API或扩展本机以用于将来的升级？

我建议您制作用于表示逻辑的API，并确保99.9％（我猜）不会受到以后Magento2 API升级的影响。

您是否建议使用额外的层来组合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。

对于Web应用程序，有很多可能性。您可以使用：

• 标准PHP解决方案（由任何框架提供支持），您可以在其中利用任何PHP模板引擎（例如Smarty，Twig，Dwoo ...）来提供HTML输出
• Java / NodeJS /您熟悉的任何语言
• 完全基于JavaScript的解决方案，它将呈现所有HTML，并会通过ajax调用相应的API，以向其中填充数据
• 这些方法的任何混合/组合

这不是按书单排列的，我只是分享了几种组合。实际上，您的想象力是唯一的限制。

最后的想法

尽可能多地使用基于javascript的解决方案，因为它可以为客户提供更好的体验，页面加载的有效负载较小，如果可以预测客户的下一步操作，甚至可以进行推测性数据加载。

但是，纯JavaScript解决方案的问题是SEO。如果您所有的数据都是通过Ajax加载的，则Google可能无法解析它。

解决方案是制作一个混合应用程序，该应用程序在首次加载时（例如，当您点击/ catalog / shoes时）将提供整个HTML页面。为了在站点中进行任何进一步的导航，您可以利用ajax仅获取所需的块。

一种方法是创建页面快照，例如通过使用PhantomJS。与此相关的付费解决方案也很少，例如：

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

我的公司创建了两个项目，我可以分享一些有关开发无头的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端点。

最棘手的部分是结帐。尽管为无头模式做好了准备，但仍有一些部件需要进行特殊调整。如果您使用的是贝宝，那么通常您将被重定向到贝宝站点以使用某些令牌来付款。对于我们来说，此令牌需要单独获取，因为我们不遵循标准重定向方式。类似的情况是与挂钩Adyen有关，在下订单后需要重定向。标准magento端点仅在成功时返回订单ID，并且不允许注入重定向URL。我们在实施3dSecure时也遇到了一些问题。

在大步向前之前要考虑并向客户说明的一件主要事情是，对于您的特定实现，将需要重写外部模块的所有与前端相关的部分。目前，模块无法将自己的数据添加到任何无头的部分。该模块唯一可以做的就是提供API端点。

总而言之，无头的magento绝对是可能的。我们最终有了用于这些调整的自定义模块和可以与其他项目一起使用的新端点。

由于React Front可以缓存很多东西，并且节点后端非常快，因此React Front可以很好地工作。我们以这种方式删除了查看标准magento请求所需的时间。

如果要检查其行为，请访问以下项目链接：

https://therake.com/

https://www.emperia.ch/

如果有人说荷兰语，也可以查看有关雷蛇的这篇文章：http : //www.marketingfacts.nl/berichten/headless-magento-2-de-toekomst-van-e-commerce

[更新]

有关结帐流程问题的更新。当我写结帐是棘手的。api级别的支付网关基本上不存在。例如，在常规结帐中，大多数付款网关会将您重定向到其他站点以完成付款。这些模块中的某些模块正在magento中以待处理状态创建订单，某些模块（贝宝快递）会在创建订单之前进行重定向。这些重定向通常依赖您的会话以在返回后获取详细信息。这是一个问题，因为placeOrder api端点仅返回新创建的订单的ID，而不返回重定向的信息。由于我们也没有直接点击magento，而是节点后端，因此从网关返回时，需要正确还原会话。我们当前的项目集成了Paypal和Adyen网关，这花了我们150多小时。

这是开源项目https://github.com/ishakhsuvarov/going-headless

该存储库是根据Imagine 2017 DevExchange会议的一部分“无头”讨论创建的，以收集和讨论有关使用Magento的Web API和自定义前端的想法。该项目的主要目标是收集Web API流程中最关键和最痛苦的点，并开发解决方案，这将满足大多数用例。