软件技术学习笔记

传统单页面应用(SPA)是整体一块部署上线，服务器返回不同的SPA版本即可。而微前端是要求每小块APP都可以独立部署上线，同时又提供SPA般的体验。为了满足微前端+SPA的需求，服务器需要有动态返回每小块APP对应版本的能力。只使用Nginx部署前端资源，是无法达到这个目标。

先看看我们如何设计react-micro-frontend-server-go来满足Demo网站的微前端服务诉求，再探讨一下满足7x24小时微前端的运维平台应该有哪些特点。

本地部署样例，见: https://github.com/kinsprite/react-micro-frontend-server-go/releases/tag/v2.3.0

大系统拆分成微前端之后，为了提升用户体验，都是按需延时加载相关的CSS/JS。微前端框架react-micro-frontend-framework的职责：

1. 提供微前端APP注册接口。有了注册接口才能让框架反向找到微前端APP的React组件。
2. 作为整个前端的底座，负责启动React框架、渲染root节点，提供按需渲染某个微前端APP的接口——React中以组件的方式。
3. 找到相关微前端的资源位置，按照依赖次序加载CSS/JS。
4. 提供多个微前端之间的通信机制——全局Redux Store。
5. 提供前端公共库服务——符号导出。

选择React做微前端框架的其中一个原因是：React Router支持动态路由，都是在渲染每层路由组件时判断加载什么内容。而别的路由框架就不是这个样子，有的是静态配置路由，如果它支持Middleware或者Hook机制，还能玩微前端，否则就得重新开发一个路由框架。所以，统一技术栈选择React + React Router，让微前端更加容易落地。

工程化的内容很多，但是本文只关注与微前端构建相关的内容：统一构建脚本，Webpack按规则导入/导出JS模块符号，生成元信息（入口文件路径、微前端定义信息、GitRevision等）。

虽然Create React App可以构建SPA，但是满足不了我们微前端的构建需求。同时，Create React App没有提供可回调的方式让我们扩展，于是只能新建构建脚本：react-micro-frontend-scripts。该项目脚本内容大部分来源于Create React App，目前只支持TypeScript + ESLint + PostCSS。在实际项目中，可以调用该项目脚本，使用函数回调的方式定制自己的内容。在几个微前端App样例中，也是这种方式使用，有的已添加自身的定制参数。

在前端领域，用户体验放到第一位。在复杂业务操作的前端项目中，SPA的体验要比多页面或iframe嵌套的效果好很多。我们不能为了代码解耦、浏览器中无冲突而放弃SPA。

在以前的项目中，我们已经使用npm发包的方式将代码分割到多个仓库。在集成前端应用时，再使用npm和Webpack工具构建成一个SPA。但仍有一个明显的缺点：每次底层组件更新时，上层SPA都需要重新集成打包、部署。同时，底层组件个数不少又经常更新，上层SPA频繁地集成与部署，让人很反感。

参照后端微服务，微前端（或称为前端微服务）也应该有以下特点：独立开发、独立部署、灰度发布。选择Micro frontends + SPA是最佳的DevOps与体验方案。经过几天的奋战，已经实现了一个基于React框架的微前端Demo，见： https://micro.qinzhiqiang.cn 。

使用Docker构建前端工程时，按照常规方法从node:tls镜像开始下载依赖包，构建的大部分时间都耗在npm依赖包下载了。为了提高前端的构建速度，我们可以把工程的依赖包先缓存到镜像中，再构建工程时就不需要从远程下载。因yarn可以锁定依赖包的版本，我们使用yarn代替npm工具，避免npm工具每次下载底层依赖包的版本可能不同。

本文代码: https://github.com/kinsprite/react-my-app-ts

一个框架如果有中间件机制，后续的可扩展性就很强，Redux就是这种一个数据处理框架。Redux中间件机制代码很短，但是理解起来可不是一句话讲得完。要看明白其中间件机制，主要看 createStore() 和 applyMiddleware() 这两个函数。