內容簡介
目前業界的軟體開發多半依照不同技術採水平分工模式, 例如：一組負責前端、一組負責後端, 但這跟一般企業的組織劃分有所不同, 導致所有開發案都必須跨部門、跨開發團隊進行協調, 團隊溝通變得越來越麻煩, 在經典之作《人月神話》(The Mythical Man-Month) 一書中就描述了這個情況。
▌擺脫傳統單體應用的思維, 現在就將微前端導入你的專案中！ ▌
微前端架構提倡的則是另一種做法：將應用程式垂直拆解, 每個區塊交給一個專責團隊負責, 一條龍地包含從資料庫連接到使用者介面的開發。不同團隊的前端單元會在客戶端的瀏覽器內整合, 構成最終的頁面。用更容易理解的說法, 微前端就像是帶有使用者介面的微服務架構。
聽起來是要每個開發團隊各自為政, 相信有經驗的開發者可能馬上會想到：那採用不同的技術怎麼整合？會不會有效能瓶頸？類似的功能應該很容易重複開發吧？後端伺服器要各自架設？版本控制要各自維護？各做各的那介面怎麼統一？
微前端架構當然不可能毫無缺點, 以團隊的角度, 程式碼或資源的冗餘自然是無可避免, 不過只要配套機制運作得當, 所帶來的可擴展性、靈活性，仍然是利大於弊。本書就要教你怎麼無痛建構、轉換到微前端的開發架構。
別擔心要多學新的框架, 雖然確實有一些完全符合微前端概念的框架可以直接套用, 但作者想強調的是微前端架構的概念和選用時機, 若強迫用特定的框架, 很有可能馬上澆熄你的熱情。因此本書會在現有常見的網路技術規範下, 引入微前端的基本機制, 不管你的網站或應用程式採用哪種技術所建構, 幾乎都可以適用。
為了適用各種不同的情境, 作者提供了超過 20 個開發上的使用案例, 協助你將手上專案順利導入微前端的開發架構。除了技術上的交流, 作者也在書中提供不少團隊開發該留意的經驗分享, 界定好開發團隊的責任歸屬, 做好跨團隊間的溝通協調, 讓微前端架構發揮最大價值。
如果你受夠巨無霸一大包的前端單體架構所帶來的諸多困擾, 有了上述這些指引, 現在正是導入微前端架構的好時機, 對於新一代網頁開發人員、架構師或團隊領導者, 相信會帶來非常大的助益。
本書特色:
全書共收錄超過 20 個微前端架構的使用案例, 從簡單的超連結、iframe 和 Ajax 入門, 到較為複雜的 SSI 伺服器端內嵌、ESI、Tailor、Podium、Web Components 以及 app shell、通用渲染等, 並且讓你可以靈活將這些工具和技巧應用於真實情境中。
● 將不同的應用程式建構為統一的前端頁面。
● 無縫整合採用各種框架的 JavaScript 程式碼。
● 各種伺服端與客戶端的整合技術與頁面路由技巧。
● 協助釐清專案需求, 挑選正確的架構及整合技術。
● 建構設計系統的樣式庫, 提供一致性的 UI/UX。
● 提高團隊開發效率並優化專案執行流程。
▌擺脫傳統單體應用的思維, 現在就將微前端導入你的專案中！ ▌
微前端架構提倡的則是另一種做法：將應用程式垂直拆解, 每個區塊交給一個專責團隊負責, 一條龍地包含從資料庫連接到使用者介面的開發。不同團隊的前端單元會在客戶端的瀏覽器內整合, 構成最終的頁面。用更容易理解的說法, 微前端就像是帶有使用者介面的微服務架構。
聽起來是要每個開發團隊各自為政, 相信有經驗的開發者可能馬上會想到：那採用不同的技術怎麼整合？會不會有效能瓶頸？類似的功能應該很容易重複開發吧？後端伺服器要各自架設？版本控制要各自維護？各做各的那介面怎麼統一？
微前端架構當然不可能毫無缺點, 以團隊的角度, 程式碼或資源的冗餘自然是無可避免, 不過只要配套機制運作得當, 所帶來的可擴展性、靈活性，仍然是利大於弊。本書就要教你怎麼無痛建構、轉換到微前端的開發架構。
別擔心要多學新的框架, 雖然確實有一些完全符合微前端概念的框架可以直接套用, 但作者想強調的是微前端架構的概念和選用時機, 若強迫用特定的框架, 很有可能馬上澆熄你的熱情。因此本書會在現有常見的網路技術規範下, 引入微前端的基本機制, 不管你的網站或應用程式採用哪種技術所建構, 幾乎都可以適用。
為了適用各種不同的情境, 作者提供了超過 20 個開發上的使用案例, 協助你將手上專案順利導入微前端的開發架構。除了技術上的交流, 作者也在書中提供不少團隊開發該留意的經驗分享, 界定好開發團隊的責任歸屬, 做好跨團隊間的溝通協調, 讓微前端架構發揮最大價值。
如果你受夠巨無霸一大包的前端單體架構所帶來的諸多困擾, 有了上述這些指引, 現在正是導入微前端架構的好時機, 對於新一代網頁開發人員、架構師或團隊領導者, 相信會帶來非常大的助益。
本書特色:
全書共收錄超過 20 個微前端架構的使用案例, 從簡單的超連結、iframe 和 Ajax 入門, 到較為複雜的 SSI 伺服器端內嵌、ESI、Tailor、Podium、Web Components 以及 app shell、通用渲染等, 並且讓你可以靈活將這些工具和技巧應用於真實情境中。
● 將不同的應用程式建構為統一的前端頁面。
● 無縫整合採用各種框架的 JavaScript 程式碼。
● 各種伺服端與客戶端的整合技術與頁面路由技巧。
● 協助釐清專案需求, 挑選正確的架構及整合技術。
● 建構設計系統的樣式庫, 提供一致性的 UI/UX。
● 提高團隊開發效率並優化專案執行流程。
作者簡介
作者介紹Michael Geers
本書作者 Michael Geers 是一位專注於建構使用者介面的軟體工程師, 目前任職於德國奧斯納貝克的一間電子商務服務公司, 過去十多年參與許多大型的電子商務專案, 他熱愛各種前端技術, 並熱衷於系統設計與改善網頁性能, 也是 micro-frontends.org 網站的創辦人。譯者介紹
本書作者 Michael Geers 是一位專注於建構使用者介面的軟體工程師, 目前任職於德國奧斯納貝克的一間電子商務服務公司, 過去十多年參與許多大型的電子商務專案, 他熱愛各種前端技術, 並熱衷於系統設計與改善網頁性能, 也是 micro-frontends.org 網站的創辦人。譯者介紹
目錄
▌第一篇 踏上微前端的道路 ▌
第 1 章 章 何謂微前端？
1.1從大處著眼──微前端概觀
1.2微前端解決了那些問題？
1.3微前端的缺點
1.4你何時應該採納微前端？
第 2 章 我的第一個微前端專案：超連結及 iframe 整合
2.1拖曳機商店
2.2透過超連結轉頁
2.3透過iframe來組合頁面
2.4接下來做什麼？
▌第二篇 路由、整合及溝通 ▌
第 3 章 以 Ajax 整合區塊並使用伺服器端路由
3.1透過Ajax整合
3.2透過Nginx做伺服器端路由
第 4 章 伺服器端整合：SSI 與代理伺服器
4.1透過Nginx與伺服器端內嵌(SSI)來整合
4.2頁面區塊出錯的處理方式
4.3深入了解標記檔整合的效能
平行載入、巢狀頁面區塊、延遲載入、首位元組時間(TTFB)及串流
4.4其他解決方案的快速介紹
邊緣內嵌(ESI)、ZalandoTailor、Podium
4.5伺服器端整合的優缺點
第 5 章 客戶端整合：使用 Web Components及 Shadow DOM
5.1以WebComponents封裝微前端區塊
5.2使用ShadowDOM做樣式分離
5.3使用WebComponents做整合的優缺點
第 6 章 溝通模式：網址、屬性與事件
6.1使用者介面溝通
主頁面對頁面區塊、頁面區塊對主頁面、頁面區塊對頁面區塊、以BroadcastChannelAPI、適合使用跨UI溝通的時機
6.2其他溝通機制
全域contextinformation及身分驗證.、管理狀態、前後端溝通、資料複製
第 7 章 客戶端路由與 app shell：統一單體應用程式
7.1平面式路由的appshell
7.2appshell與雙層路由
7.3快速認識single-spa元框架
7.4開發統一單頁應用程式的挑戰
第 8 章 前後端整合技巧及通用渲染
8.1結合伺服器端及客戶端整合
SSI及網頁元件、團隊之間的契約、其他解決方案
8.2何時該使用通用渲染？
第 9 章 我的專案適合何種架構？
9.1專有名詞回顧
9.2複雜度比較
9.3你是在打造網頁還是應用程式？
9.4挑選正確的架構及整合技術
▌第三篇 如何做得快、一致且有效率 ▌
第 10 章 載入資源最佳化
10.1資源參照策略
直接參照、快取破壞及獨立部署、透過重新導向來參照、透過include來參照、同步標記語言檔及檔案版本號、行內程式碼、Tailor、Podium等整合方案
10.2bundle (打包檔) 的拆分程度
HTTP/2、全包bundle、團隊bundle、頁面及頁面區塊bundle
10.3隨選載入...
第 1 章 章 何謂微前端？
1.1從大處著眼──微前端概觀
1.2微前端解決了那些問題？
1.3微前端的缺點
1.4你何時應該採納微前端？
第 2 章 我的第一個微前端專案：超連結及 iframe 整合
2.1拖曳機商店
2.2透過超連結轉頁
2.3透過iframe來組合頁面
2.4接下來做什麼？
▌第二篇 路由、整合及溝通 ▌
第 3 章 以 Ajax 整合區塊並使用伺服器端路由
3.1透過Ajax整合
3.2透過Nginx做伺服器端路由
第 4 章 伺服器端整合：SSI 與代理伺服器
4.1透過Nginx與伺服器端內嵌(SSI)來整合
4.2頁面區塊出錯的處理方式
4.3深入了解標記檔整合的效能
平行載入、巢狀頁面區塊、延遲載入、首位元組時間(TTFB)及串流
4.4其他解決方案的快速介紹
邊緣內嵌(ESI)、ZalandoTailor、Podium
4.5伺服器端整合的優缺點
第 5 章 客戶端整合：使用 Web Components及 Shadow DOM
5.1以WebComponents封裝微前端區塊
5.2使用ShadowDOM做樣式分離
5.3使用WebComponents做整合的優缺點
第 6 章 溝通模式：網址、屬性與事件
6.1使用者介面溝通
主頁面對頁面區塊、頁面區塊對主頁面、頁面區塊對頁面區塊、以BroadcastChannelAPI、適合使用跨UI溝通的時機
6.2其他溝通機制
全域contextinformation及身分驗證.、管理狀態、前後端溝通、資料複製
第 7 章 客戶端路由與 app shell：統一單體應用程式
7.1平面式路由的appshell
7.2appshell與雙層路由
7.3快速認識single-spa元框架
7.4開發統一單頁應用程式的挑戰
第 8 章 前後端整合技巧及通用渲染
8.1結合伺服器端及客戶端整合
SSI及網頁元件、團隊之間的契約、其他解決方案
8.2何時該使用通用渲染？
第 9 章 我的專案適合何種架構？
9.1專有名詞回顧
9.2複雜度比較
9.3你是在打造網頁還是應用程式？
9.4挑選正確的架構及整合技術
▌第三篇 如何做得快、一致且有效率 ▌
第 10 章 載入資源最佳化
10.1資源參照策略
直接參照、快取破壞及獨立部署、透過重新導向來參照、透過include來參照、同步標記語言檔及檔案版本號、行內程式碼、Tailor、Podium等整合方案
10.2bundle (打包檔) 的拆分程度
HTTP/2、全包bundle、團隊bundle、頁面及頁面區塊bundle
10.3隨選載入...
內容試閱
我的專案適合何種架構？
首先要問自己的問題是：專案是要用來達成什麼目的？人們造訪這個網站, 是為了存取內容, 還是要使用某項特定功能？
【文件─應用程式光譜】
為了讓各位更好想像, 我們來看兩個極端案例：
● 內容取向：想像一個簡單的部落格, 使用者可以瀏覽文章, 並在專門的文章頁面上閱讀完整內文。
● 行為取向：想像一個線上繪圖程式, 使用者可以到站上以手指繪圖, 並將畫作匯出成圖檔。
內容對第一個網站非常重要, 但第二個網站並不提供內容, 純粹提供功能給使用者。不過在大型專案中, 界線不會如此壁壘分明, 這時文件─應用程式光譜就派上用場了。概念是上述兩個例子分屬光譜的兩端, 此處我們用以下簡圖表示, 只要記得越往左表示網站為內容取向, 適合伺服端渲染技術；越往右表示行為取向, 適合客戶端渲染技術, 位於中間則屬於漸進式應用, 可採用通用渲染技術。
文件(內容取向) ←–––––––––––→ 應用程式(行為取向)
我們來看兩個範例。亞馬遜購物網站位在量表的哪個位置？亞馬遜提供了許多功能, 使用者可以搜尋、排序並過濾產品清單, 還能評價商品、管理退貨、或是和線上客服人員交談。但本質上, 亞馬遜是以內容為取向的網站。一個有助於判別的好問題是：『如果去除掉所有行為, 這個網站是否還有用處？』就亞馬遜網站來說, 答案是肯定的。額外的功能無疑很重要, 但若沒有產品, 這些功能都形同虛設。因此, 我們會把亞馬遜擺在光譜偏左的地方。對於類似的微前端網站, 保險的做法是從伺服器端渲染著手, 再視情況看是否要升級到通用渲染。
接著來看第二個範例。[CodePen.io](http://codepen.io/) 是個線上程式編輯器, 讓網頁開發人員和設計師能即時預覽 HTML、CSS 及 JS 程式碼合併的效果, 勾勒其構想或是尋找潛在錯誤。CodePen 也有一個活躍的線上社群, 許多人會在上頭展示自己的作品並分享程式碼。只要瀏覽 CodePen.io (http://codepen.io/) 上的公開目錄, 你就能找到一大堆振奮人心的新技術。那麼 CodePen 會落在光譜的哪個位置？這個問題較難回答, 因為無論是行為取向的線上編輯器, 還是內容取向的公開目錄, CodePen 在這兩方面都很強。若去掉 CodePen 所有的行為, 線上編輯器就不復存在；假若移除所有內容, 目錄則會不見, 但線上編輯器還會繼續存在, 因此, 我們可能會將 CodePen 定位在光譜中間。如果我們要以微前端架構來重新開發 CodePen, 會編制兩個團隊：編輯器團隊及目錄團隊。編輯團隊會選用客戶端整合, 目錄團隊則可能採用伺服器端路由。這樣便會是一個好起點。
但若要找出最佳的微前端架構, 我們就得進一步分析各種使用案例。我們的某個團隊是否需要整合另一個團隊的內容？使用者在網站上的動線為何？這些都是得繼續深究的問題。
【挑選正確的架構及整合技術】
我們接著來看, 如何以一套具體的方法判斷你的專案需要何種架構及整合方式。你要依序問自己這幾個問題：
● 是否需要高度分離？
● 需要快速的首次頁面載入嗎？
● 需要即時使用者回饋嗎？
...
首先要問自己的問題是：專案是要用來達成什麼目的？人們造訪這個網站, 是為了存取內容, 還是要使用某項特定功能？
【文件─應用程式光譜】
為了讓各位更好想像, 我們來看兩個極端案例：
● 內容取向：想像一個簡單的部落格, 使用者可以瀏覽文章, 並在專門的文章頁面上閱讀完整內文。
● 行為取向：想像一個線上繪圖程式, 使用者可以到站上以手指繪圖, 並將畫作匯出成圖檔。
內容對第一個網站非常重要, 但第二個網站並不提供內容, 純粹提供功能給使用者。不過在大型專案中, 界線不會如此壁壘分明, 這時文件─應用程式光譜就派上用場了。概念是上述兩個例子分屬光譜的兩端, 此處我們用以下簡圖表示, 只要記得越往左表示網站為內容取向, 適合伺服端渲染技術；越往右表示行為取向, 適合客戶端渲染技術, 位於中間則屬於漸進式應用, 可採用通用渲染技術。
文件(內容取向) ←–––––––––––→ 應用程式(行為取向)
我們來看兩個範例。亞馬遜購物網站位在量表的哪個位置？亞馬遜提供了許多功能, 使用者可以搜尋、排序並過濾產品清單, 還能評價商品、管理退貨、或是和線上客服人員交談。但本質上, 亞馬遜是以內容為取向的網站。一個有助於判別的好問題是：『如果去除掉所有行為, 這個網站是否還有用處？』就亞馬遜網站來說, 答案是肯定的。額外的功能無疑很重要, 但若沒有產品, 這些功能都形同虛設。因此, 我們會把亞馬遜擺在光譜偏左的地方。對於類似的微前端網站, 保險的做法是從伺服器端渲染著手, 再視情況看是否要升級到通用渲染。
接著來看第二個範例。[CodePen.io](http://codepen.io/) 是個線上程式編輯器, 讓網頁開發人員和設計師能即時預覽 HTML、CSS 及 JS 程式碼合併的效果, 勾勒其構想或是尋找潛在錯誤。CodePen 也有一個活躍的線上社群, 許多人會在上頭展示自己的作品並分享程式碼。只要瀏覽 CodePen.io (http://codepen.io/) 上的公開目錄, 你就能找到一大堆振奮人心的新技術。那麼 CodePen 會落在光譜的哪個位置？這個問題較難回答, 因為無論是行為取向的線上編輯器, 還是內容取向的公開目錄, CodePen 在這兩方面都很強。若去掉 CodePen 所有的行為, 線上編輯器就不復存在；假若移除所有內容, 目錄則會不見, 但線上編輯器還會繼續存在, 因此, 我們可能會將 CodePen 定位在光譜中間。如果我們要以微前端架構來重新開發 CodePen, 會編制兩個團隊：編輯器團隊及目錄團隊。編輯團隊會選用客戶端整合, 目錄團隊則可能採用伺服器端路由。這樣便會是一個好起點。
但若要找出最佳的微前端架構, 我們就得進一步分析各種使用案例。我們的某個團隊是否需要整合另一個團隊的內容？使用者在網站上的動線為何？這些都是得繼續深究的問題。
【挑選正確的架構及整合技術】
我們接著來看, 如何以一套具體的方法判斷你的專案需要何種架構及整合方式。你要依序問自己這幾個問題：
● 是否需要高度分離？
● 需要快速的首次頁面載入嗎？
● 需要即時使用者回饋嗎？
...