大型前端項目結構設計

將模塊化的思想進行到底

這個結構也是咱們項目目前正在使用的,應對兩三百個頁面的web項目是沒有任何問題的,在擴展性,多人合做方面是很是優秀的。廢話很少說,先上結構,再說爲何要這麼作。前端

├── service                         # 後端接口管理
│   ├── index.js                    # 接口管理出入口
│   └── ...                         # 具體的不一樣業務/服務接口文件【S-1】
├── assets                          # 項目依賴資源管理
│   └── imgs                        # 圖片資源
│   ├── style                       # 樣式資源
│   └── js                          # 依賴的第三方sdk之類的js資源
├── components                      # 項目組件目錄
│   ├── public                      # 公共組件/基礎組件(好比基礎的按鈕/輸入框等)
│   │   ├── index.js                # 基礎組件的註冊文件【可選】
│   │   ├── README.md               # 組件使用說明文檔【可選】
│   │   └── ...                     # 組件
│   └── ....                        # 基礎性的業務組件(有詳細說明)【C-1】
├── pages                           
│   ├── modules                     # 具體業務所歸屬的文件夾(能夠用業務名稱做爲文件夾名字)
│   │   ├── components              # 業務所用到的組件
│   │   ├── views                   # 業務的全部頁面
│   │   ├── utils                   # 業務的工具集
│   │   ├──	static                  # 業務所用到的靜態資源
│   │   ├── service                 # 業務的後端接口管理
│   │   ├── store                   # 業務所用到的狀態庫(本結構基於Vue,這裏是業務的Vuex)
│   │   └── index.js                # 業務的惟一出口(包含路由與狀態庫)
│   └── ....                        # 其餘業務【P-1】
├── config                          # 項目的基礎配置
│   ├── index.js                    # 配置文件的出入口
│   └── ...                         # 具體的配置文件【C-2】
├── router                          # 項目的路由管理
│   ├── index.js                    # 路由出口
│   └── ...                         # 與路由有關的其餘文件【R-1】
├── store                           # 項目狀態庫的管理
│   ├── index.js                    # 項目狀態庫的出入口
│   └── ...                         # 具體的基礎模塊【S-2】
├── utils                           # 項目所用的工具集(封裝的請求,表單的驗證函數,時間格式化.....的工具)
│   ├── index.js                    # 工具的入口
│   └── ...                         # 具體的各個工具(請求封裝、正則、驗證......)【U-1】
├── main.js                          
├── App.vue
複製代碼

首先,這個結構是基於Vue來設計的,設計思路來源於小程序分包加載機制。示例的結構主要爲src 目錄下。vue

雖然給出的結構是基於Vue,可是其餘像小程序,React等也是可使用的,核心思想都是將具體的一個一個的業務做爲一個獨立模塊的,而後將一個一個的模塊組成一整個項目。nginx

接下來對標註的序號作下說明web

  • S-1:小程序

    • s-1部分的接口管理,主要用來存放項目的基礎接口,例如數據埋點等,不影響具體業務功能使用的接口後端

    • 若是這類的接口數量很是大,能夠根據不一樣的類型劃分或者根據所屬的服務劃分(咱們的項目後端是微服務架構,前端接口根據服務劃分的)爲多個文件,而後將其導出;再在index.js中將不一樣類型的接口文件導入後作總體導出。瀏覽器

    • 若是這類接口數量並不大,則能夠直接在index.js中進行管理導出。bash

    • 若是說再可預見的範圍內這類接口不會變多,甚至能夠徹底不要service 文件夾,將index.js 命名爲service.js 放在根目錄(src)下架構

  • C-1:框架

    • 基礎性的業務組件能夠爲整個項目共有的惟一的登陸註冊所用的組件,也能夠爲整個項目共有的header或者導航等組件
    • 若是你選擇將這些基礎性的組件,好比登陸註冊業務的組件放在業務的模塊中;在components 中僅存放公共/基礎組件,那能夠直接將public 中的文件放在components 下,去掉pubilc 文件夾
  • P-1:

    • modules 爲每個具體的業務,擁有獨立的路由,獨立的狀態庫,獨立的工具庫... modules 的目的就是將一個業務做爲一個總體封閉起來,只留一個對外的出口index.js ,如此,當公司有一個同類型的項目出現一樣的業務,能夠很是方便的進行遷移。

    • static 存放靜態資源,utils 存放工具集,若是你的業務靜態資源只有很少的一些圖片,工具集只有一兩個文件,徹底能夠將兩個文件夾保留一個便可。

    • store 是業務的狀態庫,基於 Vuexmodule 設計,內部能夠根據須要再自行劃分,但終都須要進行導出。

    • index.js 是業務惟一的對外出口,凡是須要供外部使用的(業務頁面的路由,業務的狀態庫)文件,到須要導入至index.js 後再來作總體導出。

  • C-2:

    • config 是一個可選的配置,主要用來存放項目相關的配置。
    • 若是說你的項目是要提供給不一樣的客戶來使用,每一個客戶都有本身特殊的需求,好比系統的logo須要使用客戶特定的logo,系統的title須要使用客戶提供的內容,甚至客戶說我須要ACE三個業務,不要BDF三個功能,咱們均可以給不一樣的客戶寫入不一樣的配置,在根據不一樣的配置來打包生成不一樣功能的系統具體內容能夠看個人另外一篇文章:vue不一樣環境打包命令配置 中的場景二
  • R-1:

    • 路由這裏沒什麼須要特殊說明的,就是將各業務暴露的路由導入便可。
    • 若是其餘與路由相關的文件,甚至能夠直接將路由文件移至src 下,刪除router 文件夾
  • S-2:

    • store 中放的是基礎的、不影響業務使用的、無耦合數據,以及store 對外提供的出口文件
    • index.js 及將各業務對外暴露的store導入進來,處理以後再作總體導出。
  • U-1:

    • utils 下也就是基礎性的工具集,例如封裝的請求等

結構的功能說明也就這些。

爲何要這麼設計呢,最大的緣由仍是解耦和提升複用性,於我所在公司而言,咱們有多個類似的管理系統,可能有部分業務在這個系統上有,其餘系統上產品說也要上這個功能,那根據這個結構,我就能夠直接將對應的功能模塊複製到另外一個系統中去,而後將業務暴露的出口接入到另外一個系統中,直接就能夠完成功能的遷移。

使用微前端來管理大型項目

上面的結構是咱們項目正在使用的,hold住兩三百各頁面的項目仍是比較輕鬆的,但項目在可預期的範圍內正在往更大型進化,難保上面的結構還能繼續支撐。因此咱們須要探尋更合理的架構來支撐咱們的項目,計劃引入微前端的概念。

微前端是什麼

微前端的概念來源於後端微服務架構,對於一個超大型的項目,直接管理是確定不方便的。因此咱們能夠將一個超大型項目根據業務來拆分紅多個小項目,將每個小項目交給不一樣團隊去開發,不依賴具體的技術棧,最終將這些小項目組成一個完整系統。這就是微前端。

有什麼優勢

項目管理方便,這是確定的,將一個大型項目層層拆分,不一樣團隊開發不一樣業務,各團隊自行管理,相對直接去管理一整個大型項目更方便。

不依賴特有的技術棧, 微服務化的前端,每個項目均可以根據開發團隊的習慣來使用他們更熟悉的技術棧。

解耦, 微前端後,各個項目的耦合性更低,業務間的影響會更小。

增量升級, 不管是改bug,仍是升級迭代,咱們只須要在對應的業務中去改,改完以後獨立發版,哪怕出現重大事故,只須要屏蔽對應業務便可,不會形成整個項目崩塌。

獨立部署

如何將各項目組合集成

相對於拆分而言,如何將完成後的各個小項目組合成一個總體,這部分就不太容易了,但這部分更加劇要。

iframe, 第一種集成思路是使用iframe 來集成,在iframe 中加載不一樣的項目包。

nginx, 第二種思路是經過nginx 配置代理,將不一樣的路由經過nginx 轉發到不一樣的項目。

前兩種是最容易想到的集成方案,各有優缺點,也各有不一樣的適用場景。

雲上打包編譯, 這個思路來源於Jenkins ,每一個項目向外暴露一個配置文件,告訴打包系統須要如何打包加載。

本地打包雲上集成, 集本地打包完成後,將配置文件和打包後的文件上傳雲上,打包系統根據根據配置文件來決定須要捨棄那些文件,如何加載文件。

上面這兩種集成方式,目前只是一個實現思路,可能還須要主系統或者各業務項目提供一些對外變量,告訴瀏覽器各業務須要渲染在什麼位置。

總結

微前端以後確定是大型項目架構的首選,遺憾的是目前並無開源的微前端解決框架/方案,因此若是你的項目須要使用微前端來解決問題,在目前階段。可能須要你們一塊兒來踩坑了,諸君共踩!!

相關文章
相關標籤/搜索