在大型微服务系统中,你的single-spa基础配置和每个应用程序都应该有自己的git仓库。如何在JavaScript项目中实现这一点暂无定论,因此下面列出了一些建议。
由于single-spa是一个有助于组织扩展的框架,因此了解如何将应用程序彼此分离是很重要的,这样开发人员和团队就可以在不相互干扰的情况下开发子应用。
大多数的微服务体系都鼓励独立的代码仓库、构建和部署。虽然 single-spa不能解决如何托管、构建或部署 代码的问题,但是这些问题与许多single-spa用户相关,因此这里讨论了一些策略。
选择 1: 一个代码仓库, 一个build包
使用single-spa的最简单方法是拥有一个包含所有代码的仓库。通常,您只有一个package.json,一个的webpack配置,产生一个包,它在一个html文件中通过<script>
标签引用。
优势:
- 最容易部署
- 单一版本(monorepo)控制的优点
劣势:
- 对于每个单独的项目来说,一个Webpack配置和package.json意味着的灵活性和自由度不足。
- 当你的项目越来越大时,打包速度越来越慢。
- 构建和部署都是捆绑在一起的,这要求固定的发版计划,而不能临时发布。
选择 2: NPM包
创建一个父应用,npm安装每个single-spa应用。每个子应用在一个单独的代码仓库中,负责每次更新时发布一个新版本。当single-spa应用发生更改时,根应用程序应该重新安装、重新构建和重新部署。
通常,single-spa应用分别使用babel或者webpack来编译。
请注意,您还可以使用monorepo方法,该方法允许单独构建,而不需要单独的代码仓库。
优势:
- npm安装对于开发中更熟悉,易于搭建。
- 独立的npm包意味着,每个应用在发布到npm仓库之前可以分别打包。
劣势:
- 父应用必须重新安装子应用来重新构建或部署。
- 中等难度搭建。
选择 3: 动态加载模块
创建一个父应用,允许子应用单独部署。为了实现这一点,创建一个manifest文件,当子应用部署更新时,它控制子应用的“上线”版本及加载的JavaScript文件。
改变每个子应用加载的JavaScript文件有很多的方法
对比
Monorepo | NPM包 | 动态加载模块 | |
---|---|---|---|
搭建难度 | 简单 | 中等 | 困难 |
代码是否独立 | No |
No |
✅ |
分开构建 | No | ✅ | ✅ |
分别部署 | No | ✅ | ✅ |
例子 |
当前内容版权归 single-spa 或其关联方所有,如需对内容或内容相关联开源项目进行关注与资助,请访问 single-spa .