你可能聽說過 BigPipe，這是一個十多年前的技術，而 BigPipe 通常都會跟“效能優化”同時被提起。微前端也是一個很早被提出的技術，但是最近幾年才開始比較流行。而目前微前端能夠解決的最大的問題恐怕就是遺留系統改造。我們可以將新技術構造的系統和舊技術構造的系統完美融合到一起，彼此構建，釋出，執行等不受干擾。 那麼 BigPipe 究竟和微前端有什麼關係呢，我為什麼要把這兩個放到一起來看？
回答這個問題之前，我們先來看下什麼是 BigPipe，以及什麼是微前端。
BigPipeBigPipe 最早上 FaceBook 用來提升自家網站效能的一個祕密武器。其核心思想在於將頁面分成若干小的構件，我們稱之為 pagelet。每一個構件之間並行執行。
那麼 BigPipe 做了什麼？和傳統方式有什麼不同呢？我們知道瀏覽器處理我們的 HTML 文件以及其中包含的 CSS，JS 等資源的時候是從上到下序列執行的。如果我們把瀏覽器處理的過程劃分為若干階段（stage），那麼這些階段之間有著明顯的時間先後關係。那麼我們能不能將其並行化，從而減少時間呢？這就是 BigPipe 的基本思想。
話不多說，我們通過一段程式碼來幫助大家理解,比如你的專案首頁是 home.html，大概這樣子：
<!DOCTYPE html><html> <head> <script> window.BigPipe = { render(selector, content) { document.querySelector(selector).innerHTML = content; } }; </script> </head> <body> <div id="pagelet1"></div> <div id="pagelet2"></div> <div id="pagelet3"></div> </body></html>瀏覽器首先載入過來就是一個佔位元素，這部分沒有 JS 和 CSS，只有 HTML 部分，因此會很快。
之後我們慢慢填充pagelet1,pagelet2, pagelet3,在使用者看來，就是一種“漸進式渲染”的效果。
服務端程式碼大概是：
const app = require('express')();const fs = require('fs');// 模擬真實場景function wirteChunk(content, delay, res) { return new Promise(r => { setTimeout(function() { res.write(content); delay); })}app.get('/', function (req, res) { // 為了簡化程式碼，直接同步讀。 強烈不建議生產環境這麼做！ res.write(fs.readFileSync(__dirname + "/home.html").toString()); const p1 = wirteChunk('<script>BigPipe.render("#pagelet1","hello");</script>', 1000) const p2 = wirteChunk('<script>BigPipe.render("#pagelet2","word");</script>', 2000) const p3 = wirteChunk('<script>BigPipe.render("#pagelet3","!");</script>', 3000) Promise.all([p1, p2, p3]).then(res.end)});app.listen(3000);從這裡我們可以看出，BigPipe 不是框架，不是新技術。我們只需要按照這樣做就行了。 這對於頁面可以細分為多個塊，塊之間關聯不大的場景非常有用。如果還是不太明白，可以看下這篇文章 -https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919/
說完了 BigPipe，我們再來看一下微前端。
微前端和後端微服務類似，“微前端是一種架構風格，其中眾多獨立交付的前端應用組合成一個大型整體。”
如果你想做微前端，一定要能夠回答出這 10 個問題。
微應用的註冊、非同步載入和生命週期管理；微應用之間、主從之間的訊息機制；微應用之間的安全隔離措施；微應用的框架無關、版本無關；微應用之間、主從之間的公共依賴的庫、業務邏輯(utils)以及版本怎麼管理；微應用獨立除錯、和主應用聯調的方式，快速定位報錯（發射問題）；微應用的釋出流程；微應用打包優化問題；微應用專有云場景的出包方案；漸進式升級：用微應用方案平滑重構老專案。這裡有一篇文件，區別與別的微前端文章的點在於其更加靠近規範層面，而不是結合自己的業務場景做的探索。這篇文章來自於阿里團隊。
文章地址： https://mp.weixin.qq.com/s/rYNsKPhw2zR84-4K62gliw
還有一篇文章也不錯，一併推薦給大家 - https://mp.weixin.qq.com/s/DVkrV_KKE9KaGSeUSenc6w
微前端中有一個重要的需要解決的問題是子系統之間的路由。而我們的 BigPipe 如果被當作一個個子應用的，那不就是微前端中的一個點麼？BigPipe 也好，微前端也好，都是一種概念，一種指導思想。微前端是不限於技術棧的， 你可以使用傳統的 ssr，也可以使用 csr，也可以使用現代 csr + ssr 等，框架也可以五花八門。 如何將這些系統組合起來，並且能夠有條不紊地進行合作完成一個完整的應用？這是微前端所研究和要解決的問題。
對於微前端，我們隔離各個應用的方式有幾種：
iframe類似 bigpipe 這種客戶端非同步載入技術web-components不管採用哪種方式，我們的大體邏輯都是：
先載入主框架非同步載入各個子應用只不過載入子應用，我們可以通過 iframe 去載入，也可以使用 web-component 去載入，也可以使用類似 bigpipe 的方式分段並行載入。我們甚至可以將這幾者進行結合使用。而 iframe 和 web-compoents 順帶解決了諸如 js 和 css 等隔離的作用，而 bigPipe 只是對資源載入的一個有效控制，其本身並沒有什麼特殊含義，更不要說諸如 js 和 css 等隔離作用了。
事物關聯當前端有了 Nodejs 之後，我們發現可以做的事情變多了，除了 BigPipe，我們又去做 ssr，又要做 graphql，還要做微前端，海報服務，AI 等等。當你從大的視角看的時候，會發現這些技術或多或少都有交集，比如我剛才提到的 ssr。 我們知道 ssr 中有一點就是我們先返回給使用者一個有內容的 html，這個 html 在服務端生成，由於在服務端生成，因此只有樣式，沒有繫結事件，所以後續我們需要在客戶端合成事件。 如果將上面 BigPipe 的程式碼拿過來看的話，會發現我們的 html markup 可以看作服務端渲染內容（可以是直接寫死的，也可以是服務端動態生成的）。之後我們輸出後續 pagelet 的 JS 程式碼到前端，前端繼續去執行。基於 BigPipe 我們甚至可以控制頁面優先順序顯示。我們再繼續去看的話， BFF 常見的一個功能“合併請求”在這裡扮演了什麼樣的角色？大家可以自己想一下。當你不斷從不同角度思考問題，會發現很多東西都有關聯。每一個技術背後往往都會落到幾個基本的原理上。了解技術初始產生背後解決的問題對於掌握一個技術來說非常重要。