这是 Jerry 2020 年的第 86 篇文章，也是汪子熙公众号总共第 268 篇原创文章。
这篇文章的视频版本如下：
https://v.qq.com/x/page/b3212…
这个分享是 SAP 2020 寰球技术大会(SAP TechEd)，“客户自主”时代的极致体验分论坛内容之一：
本文的分享次要分为以下四个方面来介绍 Spartacus.
首先，通过 Spartacus 四大个性的介绍，让大家对作为 SAP Commerce Cloud 新一代 Storefront 这个电商前台店铺利用有一个直观的理解。Spartacus 的首页如下图所示，其 logo 是一个印有闪电的购物袋，象征着 Spartacus 能为用户带来晦涩快捷的在线购物体验。
其次，通过和 Commerce Cloud 原有的基于 Accelerator 技术的 Storefront 相比拟，让大家理解 SAP 推出 Spartacus 的起因是什么。
紧接着，是 Spartacus 技术架构的简要介绍。
最初，可能是 SAP Commerce 从业者比较关心的一个话题，即 Spartacus 的公布形式和更新频率，因为这个话题也和宽广 Commerce 从业者是否决定抉择 Spartacus 密切相关。
SAP Commerce Cloud 是 SAP 一款电商解决方案，而 Storefront 这个术语，指的是该解决方案的前台店铺界面。一句话概括 Spartacus，它是基于古代 Web 开发技术和框架打造而成的一款新的 SAP Commerce Cloud Storefront.
那何谓古代呢？Spartacus 1.0 版公布于 2019 年 7 月，因而相比前一代基于 Accelerator 技术的 Storefront 来说，Spartacus 具备得天独厚的劣势，可能采取比拟成熟和古代的前端技术来开发。
Spartacus 个性之一：单页面利用 Single Page Application
这也是 Spartacus 命名的由来。所谓单页面利用，是由一个称为外壳 (shell) 的 html 页面和多个蕴含具体业务逻辑的页面片段组成。
Commerce 传统的 Storefront，基于 JSP 实现，JSP 是一种服务器端渲染技术，页面代码在 Commerce 服务器端生成。而单页面利用是一种富客户端技术，页面片段的渲染以及页面路由，放在客户端实现，这样加重了 Commerce 服务器的负载。当单页面利用的界面内容发生变化时，不须要从新加载整个外壳 html 页面，而仅仅须要更新相干的发生变化的页面片段，这样较多页面利用相比，页面之间的切换更加晦涩，用户体验更好。
Spartacus 个性之二：响应式设计和自适应设计
这是 web 利用的用户体验畛域两个容易混同的概念，因为二者都是为了解决网页在不同屏幕尺寸的设施上展现的问题。从编程角度讲，响应式设计通过各种前端技术，为页面元素赋予了依据屏幕分辨率的变动而主动调整显示行为，以达到最佳显示成果的能力。
例如 Spartacus 里的列表控件，随着屏幕宽度的减小，显示的列表栏的数目也随之缩小。而自适应设计，为不同类别的设施别离实现不同的页面，检测到设施分辨率后调用对应的网页。Spartacus 的页面设计绝大部分是响应式布局，但也反对自适应布局的个性。
Commerce 的 CMS 模块将 Storefront UI 依照性能上的逻辑相关性, 划分成不同的区域，而 Spartacus 能够容许使用者依据不同的屏幕尺寸，配置在该尺寸下，不同的区域内应该显示哪一些 UI 组件。
Spartacus 个性之三：100% API 驱动
Commerce Cloud 提供了一组称为 Omni Commerce Connect(简称 OCC)的 Restful API.
Spartacus 通过规范的 HTTP 协定调用这组 API，实现同 Commerce Cloud 交互的目标。从编程层面来说，100% 的 API 驱动确保了 Spartacus 的前后端拆散，使得 Spartacus 的二次开发人员不须要去理解 Commerce 平台 Java 层的实现细节，而过来基于 Commerce Accelerator 技术的 Storefront 二次开发，须要的是会应用 JSP 和 Java 的全栈开发者。
从更深层次来说，100% API 驱动使 Spartacus 同 Commerce 平台也解除了紧耦合关系，从而极大晋升了 Spartacus 的可降级性。这一点在接下来 Accelerator 同 Spartacus 的比照中咱们会进一步阐明。
Spartacus 个性之四：开源，收费
Spartacus 的代码是齐全开源的，托管在 Github 上。如果大家仔细观察 Github 仓库上的代码提交者列表，就会发现，这些代码贡献者有的是像 Jerry 这样的 SAP 职员，有的来自 partner 公司，还有 freelancer 即自由职业者。SAP 抉择将 Spartacus 开源，心愿构建出一个凋敝的生态圈，和开源社区里其余贡献者独特在 Commerce Storefront 畛域进行继续翻新。
那么，SAP 为什么要推出 Spartacus 呢？这得从 Spartacus 诞生之前，SAP Commerce 传统的 Storefront 实现技术即 Accelerator 说起。
Accelerator 是 Spartacus 公布之前，SAP Commerce Cloud 应用的 Storefront 实现技术。
Accelerator 是一个开箱即用的 web 实现模板，是 Commerce 平台的一部分，以源代码的形式交付给客户。客户通过一个叫做 module generator 的工具，基于 Accelerator 模板代码生成本人的 Storefront 实现，而后基于这些生成的代码持续二次开发。这种源代码生成形式的确能放慢客户的 Storefront 二次开发速度，这也是 Accelerator 命名的由来。
然而，Accelerator 这种同 Commerce 平台的紧耦合关系，以及基于源代码级别的二次开发形式，给 Commerce 我的项目施行的可降级性带来很大的挑战。例如，当客户发现新版本的 Accelerator 能满足本人新的业务需要时，心愿降级 Accelerator. 然而因为 Accelerator 是 Commerce 平台的一部分，所以必须先降级整个 Commerce 零碎，再应用 module generator 基于高版本的 Accelerator 代码，从新生成自定义实现，再把基于低版本 Accelerator 模板而进行的二次开发内容，逐个手动地迁徙到高版本 Accelerator 生成的自定义实现中去。
当 Commerce 的二次开发达到肯定规模量的时候，这种手动降级的形式很挑战。
Accelerator 具备的这些缺点，在 Spartacus 问世之后都迎刃而解。
Accelerator 通过源代码的形式提供了一个 Storefront 的开发模板，而 Spartacus 则以库的形式，提供了一个轻型的 Storefront 开发框架。咱们新建一个 Angular 利用，导入对 Spartacus 库的依赖，当咱们须要降级 Spartacus 时，只须要更新 Angular 利用的 package.json 文件里 Spartacus 库文件的版本号即可，因而 Spartacus 从可降级性上来说是一个微小的飞跃。
Spartacus 采纳 API 的形式同 Commerce 交互，这使得 Spartacus 能够同 Commerce 离开部署，别离进行降级，比方目前曾经公布的 Spartacus 3.0，反对从 Commerce 1905 开始及其之后的所有版本。
Spartacus 采纳 Angular 开发，编译之后生成 JavaScript 代码，作为其运行时语言。这样一来，应用 Spartacus 的二次开发人员，不再须要像过来开发 Accelerator 那样，不再须要把握前端 JSP 和后端 Java 的全栈开发技术栈。
Accelerator 的可扩展性，是通过就义可降级性为代价换来的。同 Accelerator 只有源代码级别的批改这一繁多的扩大形式相比，Spartacus 实现扩展性的伎俩更加多元化。
(1) Spartacus 的模块之一，ConfigModule，将业务逻辑和页面布局以及款式，通过配置的形式裸露进去。二次开发人员通过调整配置，能够更改 Spartacus 默认的行为和页面布局以及款式。
(2) Spartacus 的页面布局由不同的 Angular 组件组成，这些 Angular 组件同 Commerce 的 CMS 组件具备一一对应关系。Spartacus 容许二次开发人员加强甚至开发新的 Angular 组件，去替换 Spartacus 公布时应用的默认组件，以此来实现客户的页面定制化需要。
(3) 借助 Angular 弱小的依赖注入机制，Spartacus 容许开发人员像 Commerce 后盾开发人员应用 Java Spring 框架那样，开发本人的 service 实现。通过 Angular 的 Dependency Injection 机制，注入自开发的 service，从而达到定制化 Spartacus 的运行流程和逻辑的目标。
上面咱们来简要理解 Spartacus 应用到的一些技术栈和 Spartacus 同 Commerce 交互的基本原理。
后面说到，Spartacus 是基于古代 Web 开发技术打造而成的一个 Storefront 开发框架。因而，波及到的技术栈都是目前前端开发广泛应用的一些比拟成熟的技术。
Angular：由 Google 保护的一款 web 前端开发框架，借鉴了大量有十几二十年历史的成熟的后端开发理念，比方依赖注入、接口、注解等等，这些理念在开发 须要继续迭代和保护的大规模企业级前端利用时，显得特地有劣势。Angular 同时也是一款与时俱进的框架，比方对 TypeScript 的反对，跟 RxJS 的深度整合，对 Progressive Web Application 即 渐进式网页利用理念 第一工夫的反对等等。
Spartacus 1.0 基于 Angular 9，而目前最新的 Spartacus 3.0, 基于 Angular 10. 上个月 Google 公布了最新的 Angular 11，目前咱们团队的架构师，正在评估 Spartacus 反对 Angular 11 的技术可行性。
TypeScript: Angular 的开发语言是 TypeScript，ES5, ES6 是 JavaScript 倒退过程中呈现的两个版本，而 TypeScript 不仅是 ES6 的超集，而且是一门动态类型编程语言。2018 年有一份前端我的项目中呈现频率最高的十大谬误类型统计报告，其中前 7 位都和类型谬误无关：
而 TypeScript 的编译器 动态类型查看，能够防止不少的类型谬误。通过强类型接口，在服务实现者和服务调用者之间创立了一种契约，这种契约能升高 Spartacus 组件和服务之间的耦合性，帮忙像 Spartacus 这种 其开发者来自世界各地的开源我的项目 进行更有效率地开发。
Rxjs: Reactive Extension JavaScript，是一种响应式编程实际，Angular 是 RxJS 这个库的重度使用者。Rxjs 的外围是 Observable(可察看对象），Spartacus 的实现，应用 Rxjs 的可察看对象，封装了从 Commerce 读取业务数据的异步操作。通过 Rxjs 提供的施加在可察看对象上的各种操作符，Spartacus 能够灵便地管制 异步读取 Commerce 业务数据的时序，对 Spartacus 和 Commerce 之间的数据流进行聚合或者拆分。
Ngrx: Angular 利用应用的一个可能优雅的治理利用状态的库。Angular 和其余支流的前端框架一样，遵循组件化开发的规范，组件间通信根本都是单向数据流：父组件通过属性绑定把数据传递给子组件，子组件如果想要批改传入的数据，必须通过事件回调同父组件通信。NgRx 作为通信场景里的第三方，可能对立治理组件的状态，升高了 Spartacus 这类简单前端利用组件间状态治理的复杂度和出错的可能。
SASS：Syntactically Awesome Stylesheets 的缩写，是一种 CSS 的扩大语言，在 CSS 根底上削减了定义变量，反对代码块嵌套，继承，命名空间，父级援用等个性，大大提高了 css 的开发效率。能够说 Spartacus 可能反对从页面整体色彩格调，到控件外观 细粒度的微调，SASS 功不可没。
Jasmine：一个前端单元测试框架。
Cypress：一个端到端的自动化测试框架。
咱们通过欠缺的单元测试和端到端自动化测试，保障了 Spartacus 这种开源我的项目的代码品质。
最初，咱们开发出的 Spartacus，通过打包后，以库的模式公布到 npmjs.com 下来。
这是一张 Spartacus 同 Commerce 交互的示意图。咱们首先看图的最左边。Spartacus 同 Commerce 零碎的通信，通过 HTTP 协定调用 OCC API 实现。Connector 是 HTTP 调用的发起者，保护了动态的配置信息，即 API 的 endpoint.
比方，从 Commerce 零碎读取产品主数据，读取的字段列表以 url 参数的模式呈现在 API endpoint 里。这些字段列表能够在 Connector 的动态配置点里进行配置。Connector 并不会间接同 Commerce 交互，而是把申请转发给 Adapter，具体通信由 Adapter 实现，Connector 只负责调度 Adapter. Spartacus 公布的 Adapter 默认应用 OCC Module，即 Commerce 规范的 OCC Restful API，然而客户也能够实现本人的 Adapter，连贯 Commerce 之外的其余后盾零碎。
Connector 将 Adapter 取回的数据交给 NgRx 的 store 构造对立治理，后者的复杂度被 Façade 层所暗藏，而 Spartacus UI 组件只会同 Façade 层交互，进行数据绑定和页面展现。这体现了关注点拆散的设计准则。最初，因为 UI 组件和 Commerce 后盾组件的数据模型存在差别，因而须要 Converter，在数据从 Commerce 取回，筹备出现在 UI 之前，先要通过 Converter 转换成适宜 UI 展现的构造；反之，在 Spartacus 提交数据筹备写回 Commerce 时，也要先将数据通过 Converter 转换成 OCC API 承受的数据格式。
那么 Spartacus github 仓库里的源代码，通过什么形式公布给客户应用呢？
后面曾经提到，Spartacus 打包之后，以库的形式公布到 npmjs.com 上。这是一张 Spartacus 库文件之一，Spartacus Storefront 托管到 npmjs 网站上的截图。这个库的版本号为 2.1.3, 咱们稍后会介绍其版本机制。
Spartacus 库次要有三个实体组成：core, storefront 和 styles. 其中 storefront 蕴含了用户肉眼可见的，组成电商店铺利用外观的 UI 组件，客户能够重用和加强这个库文件里蕴含的组件。Core 这个库文件则蕴含了 Spartacus 的管制逻辑。用户能够开发本人的服务类，通过 Angular 依赖注入的机制，把自开发服务类注入到 core 框架之中。Styles 蕴含了 Spartacus 的界面款式实现，客户能够对这些款式进行定制化，或者用自开发款式来笼罩规范款式。
之前进行 Accelerator 和 Storefront 的可降级性比拟时曾经提到过，客户基于 Spartacus 库文件进行 Storefront 二次开发，并不会间接批改 Spartacus 公布的源代码。客户的二次开发代码，和 Spartacus 库文件是一种松耦合的依赖关系。客户降级 Spartacus 版本，在绝大多数状况下都不会影响到已有的二次开发代码。那么所谓的“绝大多数状况下”，具体是指什么呢？这就要从 Spartacus 的版本管理机制说起。
同绝大多数风行的开源框架和库一样，Spartacus 的版本治理也采取了所谓语义化版本的机制，版本号由主版本号，次版本号和订正版本号三局部组成，两头由小数点分隔开。
主版本号的升高，用于引入无奈向后兼容的变更或颠覆性的更新。无奈向后兼容的变更，是指 Spartacus 降级之后，之前基于低版本编写的二次开发代码，须要人工调整后能力持续工作。而颠覆性的更新，一个例子就是 Spartacus 降级到 3.0 版本之后，首次反对 B2B 的电商性能。
次版本号的减少：用于引入新性能，并且版本更新之后，已有的二次开发代码不需任何调整依然可能持续失常工作。源代码重构，性能优化等不属于 bug 修复的批改，也通过次版本号的减少而引入。
订正版本号：次要用于公布 bug 的修复。
Spartacus 的订正版本公布，以周为单位，确保应用过程中发现的 bug 能尽早失去解决。次版本的公布以月为单位，这种更新的频率有助于客户疾速地进行继续改良和继续翻新。
而主版本的更新，能够参考 SAP 官网路线图网站上的申明。
从下面这张截图中 package.json 里定义的依赖，咱们可能发现之前讲到的 core, storefront 和 styles 3 个库，再加上次要蕴含了文档和翻译的 assets 库。
其中版本号 2.1.0 之前的这个符号 ^，有个术语叫做 hat, 这是语义化版本管理机制里的范畴标识符之一，示意这个 Storefront 二次开发工程反对主版本号为 2，且次版本号大于 1 的所有 Spartacus 版本，然而不反对主版本号为 3 的 Spartacus. 换句话说，图中这个二次开发我的项目，只反对 SAP Commerce B2C 的性能，因为 B2B 的性能是 Spartacus 3.0 版本里才引入的。
最初，让咱们用一些关键字来总结明天的分享。SAP Spartacus 诞生于 2019 年 7 月，是一款满足响应式和自适应个性的古代 Storefront 利用和开发框架。同之前的 Accelerator Storefront 相比，Spartacus 在保留了原有的可定制化个性之外，具备更晦涩的用户体验和良好的可降级性，并且自身开源，无需购买额定的 license. 如果大家对 Spartacus 有趣味想深刻理解，能够去 open SAP 网站上学习 Spartacus 的公开课.
感激浏览。
更多 Jerry 的原创文章，尽在：” 汪子熙 ”: