umi-nest

基于umi-nest实现微前端子应用

写在前面

项目代码 基于umi-nest实现微前端子应用

公众号 《前端厚说》

QQ小群 713593204

一、项目背景

根据实际场景去探索更优的方案是我们应该去积极面对的。那么面对着越来越大型的项目。例如TOB 的前端开发，我们往往会遇到一些困境

• 工程越来越大，打包速度耗时越来越长
• 团队人员较多，产品功能复杂，代码冲突频繁
• 客户总是会要求不断的定制化
• 代码修改，“牵一发动全身”，不易维护
• 项目的依赖升级便会影响整个应用，潜在的风险增加
• 变成一个硕大的巨无霸应用，失去灵活性，无论是多人协作还是接入成本都会大大增加

随着微前端的兴起，慢慢业内开始对之进行探索，不断的挖坑踩坑。针对以上或者不仅仅是以上的痛点。我们决定尝试以小组 为单位，集体实践。那么我们需要面对的问题就来了

• 用户端必须是「一个系统」的体验，从域名到交互体验
• 能够根据业务功能拆分多个子应用，每个子应用可以独立开发部署
• 子应用开发尽量保证跟传统开发保持一样的开发体验，避免开发者太多学习成本
• 能够根据权限加载菜单、自由定制的dashboard，应用之间有统一的通信机制支撑，避免耦合，低耦合设计
• 兼容不同技术栈开发(框架都是由公司自研方案)
• 避免应用之间全局共享数据污染

二、技术调研

要求实现一个应用里包含其他的子应用这种效果，“不起眼” 的iframe 以及单页面应用等等均可以实现这种目的。

2.1 iframe

为了避免page之间互相影响，每个page采用统一公共的iframe加载。公共的iframe由框架设计提供相关API支撑，比如，提示、通信等。

在采用iframe来加载带来的一些问题：

• 内部蒙层无法遮罩外部框架，同时布局居中
• page页面之间的交互通信
• 页面加载缓慢(这个在接受范围内，PC客户端均加载本地静态资源保持1秒内)

2.2 单页面应用

最初是jquery技术栈，不具可行性，潜在问题太多，比如：同一个页面需要在多个区域多次展示，随着功能的叠加，选择器效率大大降低，样式的互相影响也不可避免。

2.3 微前端

业内已经有开发者对之探索，我们重点采取qiankun 这也是踩在巨人的肩膀上。那么什么是微前端

2.3.1 历史与概念

在前端的前一阶段，我们还是仅仅切图 然后后端进行套页面。慢慢地慢慢地我们开始进行前后端分离。慢慢的出现三大框架，也是主流的框架。前端还得会PS

那在2016 年时候，被提出，也是和微服务概念 有异曲同工之妙。

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.

我们可以称：微前端是一种方案，或者策略方法技术。我们可以实现由不同的团队 不同的技术 构建统一化的现代web应用程序

2.3.2 优势与挑战

即使我们不在自己的项目实践微前端，但是在面试 或者一些其他的场景中，难免会提及，就像是TypeScript 一样，凡是流行的，就是大家关注的。我们可能会想得到这样一个效果

• 服务发现
• 运行隔离
• 环境一致
• 能够增量的方式升级，更新甚至重写前端的代码
  • 大型的前端项目一定会超过几年的迭代。我们还时不时的为客户提供新功能，这样不会影响整体
• 独立部署
  • 微前端的独立部署能力也是十分关键的，正是因为有独立部署的能力，就降低了无关的风险。不管代码托管到什么位置
  • 我们应该能够在不考虑其他代码库的情况下测试部署等

那么既然有许多优势，我们实际操作起来又会遇到什么问题呢？比如说像是js代码的隔离 css样式的冲突 按需加载资源 。一些冲突我们可想而知，是再所难免的。为什么这样说，因为一个简单的项目由不同的开发人员参与难免还会出现命名的冲突。

三 、需求分析

既然明确了我们的目标，以及技术方案，以及设想到了可能带来的优势与挑战。我们拟分析一下当前的需求

3.1 技术需求

结合当前业内流行的技术栈，我们选择Reatc 结合 TypeScript

3.2 实现功能

3.2.1 后台管理

项目实现一个后台的admin 管理后台能够对数据进行操作

• 文章帖子 ：文章的增删改查操作
• 用户：用户的新增与删除以及修改用户信息
• 登录注册：注册登录用户

3.3 需求可行性

由于是实践项目我们重点分析需求的技术可行性：使用 web 前端技术 ，利用MySQL 数据库，以及TypeORM 进行数据实体的设计。在技术上可行的

3.4 流程分析

在设计之初，我们需要对子应用 的流程进行简单的分析。

3.4.1 后台管理

四、系统设计

4.1 技术栈选择

由于微前端 的概念是由 后端微服务 直接或间接产生，并且保证每个子应用能够独立运行。那就需要一套能够提供服务的接口，以及前端一套前端页面

4.1.1 后端选型

后端接口选取当下NodeJS 的上层框架NestJS 。经调研，NestJS 是一个精美的node.js 框架，考虑到使用原生的NodeJS 是有一定的成本在，包括一些 错误捕捉监控等等 。NEST 是构建高效，可扩展的 NodeJS 服务器端应用程序的框架。

优势

• 依赖注入容器 - NestJS 带有自己的DiC，这是一个在 JavaScript 世界中似乎被遗忘的实用工具，但我真的不能没有它。 有一些解决方案像 Inversify 或 Bottle，但 NestJS 有自己的解决方案。 它也支持工厂注入。
• 模块化 - 在NestJS中，处于相同域边界内的应用程序的每个逻辑部分都是一个模块，它鼓励封装。
• 可测试性 - 由于引入了 DiC 和 Modularisation，您可以根据服务构建应用程序, 使控制器的工作更容易进行测试。
• 使用 TypeScript中 - 类型很好。 你可以给一个变量分配类型，减少可能出现的错误

缺点

• 由于是基于TS 语法，上手成本较高
• 一些学习资源多在国外，国内的资源相对较少。

4.1.2 前端选型

前端的框架以及技术层出不穷，吸取他人优秀的开发实践是一件比较不错的事情。国内阿里鉴于项目的实践一般为

• 语法（或者说语言） TypeScript
• 样式 less
• 数据流 Dva
• UI antd

所以我们打算采用UmiJS ，有更好的数据流管理，更好的结合TS 与 antd 。但在实践的过程中难免会遇到一些坑 。不过可以积极拥抱社区

4.1.3 总结

4.2 架构设计

4.2.1 系统结构设计

根据上述的需求分析 我们的系统暂时分为几个模块

• 用户的注册登录模块
• 文章的管理模块
• 用户的管理模块

4.2.1 功能模块设计

4.3 数据表（数据结构）

4.3.1 用户表

4.3.2 文章表

五、业务规划

实践是检验真理的唯一标准 ， 实际开发的过程便是个遇到问题 解决问题 的过程。故拟定一份开发时间进度表

六、补充

6.1 子应用要求

• 子应用需要独立运行

• 子应用包含登录页面

• 子应用包含两个模块 模块之前要求能够通信

• 子应用必须 存在表单、表格、弹出框、图片

  功能上要有数据的增删改查一些基本开发需求

• 子应用尽量引入插件

• 子应用需要同主应用进行通信

  例如用户的登录状态，主应用登录上，子应用应该自动登录

• 子应用可以同子应用通信

6.2 初版设计图

6.2.1 登录注册

6.2.2 管理页

6.3 策划书更新记录

• 2020-06-17 第一次拟定项目的策划内容

• ……