这是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的原创文章，尽在："汪子熙":