記一次系統演變過程

對於大多數前端來講，無非就是寫寫簡單的頁面，我並非歧視前端，筆者也是前端，由於前端確確實實對於公司的總體業務的認知沒有後端的瞭解的更加深入(畢竟人家是玩數據庫的)。

筆者在剛剛作公司內部系統的時候也只是作作簡單的各個模塊系統，如今大多數公司都是使用的微前端的系統架構，以達到各個業務依賴性沒有那麼大，一樣也不會由於項目的逐漸擴大，致使項目愈來愈大，首先加載慢，再其次就是難以維護。

可是全部項目都以微前端的形式分散開，就會遇到整合的問題，因而在咱們進行瘋狂的討論，由於使用的技術棧是Vue這個因素也被考慮進去了，討論出來初版最終解決方案。

初期實現-iframe

其實對於大多數人來講，一旦說到前端項目整合的話，第一個想到的就是iframe，這種是最簡單最的方法了，大多數公司都是使用的這這種方法對項目進行整合的。

廢話咱們也就沒多說，就開始開發了，遇到的第一個問題就是跨域，由於整合全部子項的每一個都有本身的域名，承載這些子項目的框架又有本身的域名。這裏就使用了，document.domain的解決了跨域問題。跨域的問題通常都會遇到，這也並非難解決的。

除了跨域問題，還有就是各個子項目的鑑權，各個子項目須要登陸以後的token其實這個問題也不是特別困難，可是後端在作這個地方爲了保證權限的安全性考慮，token會隨着一段時間進行變化，這樣一來就不是簡簡單單的把token傳給子項目就好了，首先考慮的是，各個子項目攜帶者着token向後端請求數據的時候，當token發生變化的時候，須要通知登陸框架。

在最初考慮這個問題的時候，考慮使用postMessage進行通訊由於涉及的項目太多，並且使用postMessage方法雖然輕便，可是以爲這種方法有些臃腫，不太適用於咱們如今的總體架構方案。通過討論以後，就放棄了這個方案。爲何會放棄這個方案，由於當打開多個子頁面的時候，其中一個子項目在請求數據過程當中token發生變化了，其餘子頁面須要知道token想要知道token發生變化，就必須經過登陸框架通知，若是使用postMessage的話就實在太不方便了。

其實想要的無非是登陸框架的token改變，子項目token隨着改變，這時機智的我想到了灰常優秀的Vue，Vue是使用的是Object.defineproperty，經過該方法，各個子項目也好和登陸框架也好，只須要監控一個對象上某個自定義屬性便可，這個使用我把矛頭指向了window，雖然這樣不太好，可是針對於目前的狀況window是最好的選擇。

依賴實現結構圖：

解決了一些問題以後，也算是能夠完成了初版雖然存在不少的問題，可是確實是能夠用了。因而第一個版本就這樣匆匆忙忙的上線了，用戶反映怎麼說呢，其實也沒有那麼好，畢竟是iframe須要加載的會比較慢。還在想辦法進一步優化一些。

結構優化

時間天天都在流失，登陸平臺依舊有不少的問題，對iframe有所瞭解的同窗都應該知道，每次iframe在打開的時候都須要從新拉取資源，這個是真的是太頭疼了，然而這還不是最關鍵的問題，最關鍵的是什麼，各個子項目每一個模塊都在登陸平臺裏面，不少模塊徹底在同一個項目裏面，不少時候須要拉取相同的資源，這個實在是太難受了，做爲一個前端來說，如此大量的重複資源加載，有點沒法容忍。

有的時候各個子項目業務太大的時候，頁面加載的實在是有點過於太慢了，在最初作項目時，那個時候單頁面應用火熱（如今也有大部分公司在使用），單頁面應用就會帶來這樣的問題。

爲了解決這個問題曾經考慮過使用路由懶加載，雖然能夠實現一些資源的節約，可是，舉個例子來說的話，若是當前模塊只有一個只有表單，其餘什麼都沒有，這個使用徹底不須要使用route和stroe，其餘的在同一個項目裏面的應用仍然用到了route和stroe，致使加載該模塊的使用route和store同時也被拉取下來了，實在是讓人頭痛，自己我不須要這些東西，爲何還要加載這些東西。我想哭~~~

帶着這些疑問，開始尋求解決方案，通過一段時間的調研，發現多頁面應用徹底能夠知足我如今的需求，經過多頁面，只須要在對用的頁面的實例中掛載對應所須要的資源就能夠了。當讀取到當前這個子項目中的某個模塊的時候就能夠作到這一點了。

這樣作的好處在於當前子業務模塊，須要用到route就引入route，用到stroe就使用stroe，打開頁面也只會拉取相對應的資源。再也用擔憂當前子項目拉取一些沒有相關的資源了。

具體多頁面配置請參考：Vue-cli3多頁面配置

結構設想

雖然經過上面兩部操做，已經對性能解決了很大一部分問題，可是，身爲一個優秀的前端（咳咳咳，不要打斷我。。。暫時不接受反駁，哈哈哈）來說得話，整個框架仍是存在一些問題。

1. 登陸框架中已經存在了route和stroe這些資源，爲何子項目打開的時候，還要從新拉取一次呢？
2. 使用iframe始終不是那麼的優雅，會帶來一些不可預知的問題，或者之後一些需求甚至會致使沒法知足（雖然如今尚未遇到，可是仍是得爲之後作打算）

如下內容沒有通過實踐，還沒法知道是否能夠實現。

這個想法來自於SSR，當調研Vue的服務端預渲染的時候我發現，當客戶端頁面啓動的時候是經過，讀取客戶端導出的一個json文件，而且讀取了裏面的內容，找到對應的.js文件，既然在服務端渲染的時候能夠經過讀取對應的js文件作到頁面的渲染，那麼在前端渲染的時候是否是也能夠來一波這樣的騷操做呢？。這樣一下靈感就來了，突然就有了一個大膽的想法。

關於這裏還有一個小插曲想要說一下，我之前覺得ssr是服務端解析了js文件，可是被小夥伴給質疑了，其緣由是Node根本就沒得辦法去解析js文件。之前調研ssr的時候用到了renderToString的函數，可是，當時接收的是一個url參數，也就是前端路由，createBundleRenderer返回的對象中存在兩個函數分別是renderToString和renderToStream，其中renderToString函數接收的就是頁面中所寫的template模板內容，最後把渲染好的頁面返回給客戶端。這是我本身後來理解的，再往下就要看源碼，這裏我沒有詳細看，畢竟與該文章內容不符，這裏就不作多餘贅述了，有興趣的同窗能夠看下。這裏灰常感謝個人小夥伴指出了個人錯誤。

服務端渲染中節選的代碼：

let render = vueRender.createBundleRenderer(serverBundle,{
    template,
    clientManifest:clientBundle.data,
    renInNewContext:false
}); 
//  重點就是這裏
render.renderToString({
    url:request.url
}).then((html) => {
    respones.end(html);
}).catch(error => console.log(error));

服務端渲染請參考：手把手教你搭建SSR(vue/vue-cli+express)

若是在Vue打包的使用，能夠把各個頁面對應的css文件js統一寫入到項目中的一個json文件中，若是是這樣的話，登陸框架能夠經過域名獲取到該模塊對應的組件，而後經過動態路由route.addRoute這個api把讀取到的組件註冊到登陸頁面，這樣一來Vue、store、route、組件庫這些東西就徹底可使用，登陸框架的了。豈不是一箭雙鵰的嗎？這樣的優化真的太大了。

上圖中完成了操做以後，獲取到對應的頁面組件以後，經過路由動態注入到登陸框架中的，就好了。這些想法還在一步一步的調研過程當中。。。

總結

全部的項目不管大小，都須要演變，可是其中須要做爲開發人員的咱們，進行不斷的思考和優化，以達到一個比較好的狀態，作前端也有一段時間了，我的以爲，沒有最好的選型，只有最適合選型，只有真正符合當前項目的需求的選型纔是最正確的。

前端的路還有很長，還有太多太多的東西須要去考慮，前端所須要重視的是用戶體驗和數據交互，其實最最重要的還有就是性能。不能由於一個錯誤的想法，讓用戶以爲當前的系統變得很慢。

感謝你們閱讀這篇文章，文章中若是有什麼問題，你們在下方留言我會及時作出改正。