UmiJS-NestJS | 微前端子應用前期項目策劃

umi-nest

基於umi-nest實現微前端子應用

---

寫在前面

項目代碼 基於umi-nest實現微前端子應用

公衆號 《前端厚說》

QQ小羣 713593204

1、項目背景

根據實際場景去探索更優的方案是咱們應該去積極面對的。那麼面對着愈來愈大型的項目。例如TOB 的前端開發，咱們每每會遇到一些困境

• 工程愈來愈大，打包速度耗時愈來愈長
• 團隊人員較多，產品功能複雜，代碼衝突頻繁
• 客戶老是會要求不斷的定製化
• 代碼修改，「牽一髮動全身」，不易維護
• 項目的依賴升級便會影響整個應用，潛在的風險增長
• 變成一個碩大的巨無霸應用，失去靈活性，不管是多人協做仍是接入成本都會大大增長

隨着微前端的興起，慢慢業內開始對之進行探索，不斷的挖坑踩坑。針對以上或者不只僅是以上的痛點。咱們決定嘗試以小組 爲單位，集體實踐。那麼咱們須要面對的問題就來了

• 用戶端必須是「一個系統」的體驗，從域名到交互體驗
• 可以根據業務功能拆分多個子應用，每一個子應用能夠獨立開發部署
• 子應用開發儘可能保證跟傳統開發保持同樣的開發體驗，避免開發者太多學習成本
• 可以根據權限加載菜單、自由定製的dashboard，應用之間有統一的通訊機制支撐，避免耦合，低耦合設計
• 兼容不一樣技術棧開發(框架都是由公司自研方案)
• 避免應用之間全局共享數據污染

2、技術調研

要求實現一個應用裏包含其餘的子應用這種效果，「不起眼」 的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、系統設計

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 總結

前端	後端
基於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 第一次擬定項目的策劃內容

• ……

---