UmiJS-NestJS | 微前端子应用前期项目策划

umi-nest

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


写在前面

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

公众号 《前端厚说》node

QQ小群 713593204jquery

1、项目背景

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

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

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

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

2、技术调研

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

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、系统设计

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 ,有更好的数据流管理,更好的结合TSantd 。但在实践的过程当中不免会遇到一些 。不过能够积极拥抱社区

4.1.3 总结

前端 后端
基于umi生态的前端方案 基于NodeJS的后端方案

4.2 架构设计

4.2.1 系统结构设计

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

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

4.2.1 功能模块设计

4.3 数据表(数据结构)

4.3.1 用户表

4.3.2 文章表

5、业务规划

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

日期 前端进度 后端进度
2020-06-17 初始化前端项目 初始化后端项目

6、补充

6.1 子应用要求

  • 子应用须要独立运行

  • 子应用包含登陆页面

  • 子应用包含两个模块 模块以前要求可以通讯

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

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

  • 子应用尽可能引入插件

  • 子应用须要同主应用进行通讯

    例如用户的登陆状态,主应用登陆上,子应用应该自动登陆

  • 子应用能够同子应用通讯

6.2 第一版设计图

6.2.1 登陆注册

6.2.2 管理页

6.3 策划书更新记录

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

  • ……

相关文章
相关标签/搜索