決戰！微前端架構 Micro Frontends：新一代可擴展的網頁開發模式，實現各種框架的無縫整合與溝通
▐ 自2024/1/1 00:00起，台灣樂天市場「屈臣氏」將不贈送 LINE POINTS 點數
▐ 自2023/2/1 00:00起，樂天Kobo電子書不贈送 LINE POINTS 點數，請會員多加留意。
▐ LINE POINT點數回饋依照樂天提供扣除折價券(優惠券)、與運費後之最終金額進行計算。
▐ 愛買與愛票網、a la sha（2023/8/1生效）、GAME休閒館（2023/8/1生效）、專品藥局（2023/8/1生效）等部分店家不參與全站加碼，請詳閱LINE Points 加碼店家清單:https://lin.ee/Y2CcVdk/rcfk
▐ 注意事項
(1)部分服務及店家不符合贈點資格，購買後將不贈送 LINE Points 點數，亦不得使用點數紅包，如：比漾廣場、神腦生活、MyCard、愛美麗福利社、展翔通訊、ezcook 美食廚房、葳豐數位商城、吉盈數位商城、森林巨人、包材中心、KABO佳麗寶家電批發、LuLuLu精品店、NewSTYLE新風尚潮流、0216零食會社、美寶家電、純米小鋪、LILY科技新櫃、登芳3C電子雜貨賣場、豐饌御鴨、鼎耀通訊、誠選3C、Smile、葳豐數位商城二店、米蘭寶、BoBo Outlet代購屋、楊家食品（2022/10/1生效）、樂天Kobo電子書（2023/2/1生效）、屈臣氏（2024/1/1生效）等，請詳閱LINE Points 加碼店家清單。
(2)需透過LINE購物前往台灣樂天市場，並在同一瀏覽器於24小時內結帳，才享有 LINE Points 回饋。
(3)若購買之訂單（包含預購商品）未符合樂天市場 45 天內完成訂單出貨及結帳，則不符合贈點資格。
(4)如使用App、或中途瀏覽比價網、回饋網、Google等其他網頁、或由網頁版(電腦版/手機版網頁)切換為App都將會造成追蹤中斷而無法進行 LINE Points 回饋。
(5) LINE 購物為購物資訊整合性平台，商品資料更新會有時間差，如顯示之商品規格、顏色、價位、贈品與台灣樂天市場銷售網頁不符，以銷售網頁標示為準。
(6)Pickup店家之有效訂單需於下單後40天內使用完畢才符合分潤條件
(7) 若上述或其他原因，致使消費者無接收到點數回饋或點數回饋有爭議，台灣樂天市場保有更改條款與法律追訴之權利，活動詳情以樂天市場網站公告為準。同款比價 | 為您推薦2個賣場2個同款賣場2個同款賣場
價格低到高
商品描述
作者：Michael Geers 出版社：旗標 出版日：1120925 ISBN：9789863127109 語言：中文繁體 裝訂方式：平裝 內容簡介 目前業界的軟體開發多半依照不同技術採水平分工模式, 例如：一組負責前端、一組負責後端, 但這跟一般企業的組織劃分有所不同, 導致所有開發案都必須跨部門、跨開發團隊進行協調, 團隊溝通變得越來越麻煩, 在經典之作《人月神話》(The Mythical Man-Month) 一書中就描述了這個情況。 ▌擺脫傳統單體應用的思維, 現在就將微前端導入你的專案中！ ▌ 微前端架構提倡的則是另一種做法：將應用程式垂直拆解, 每個區塊交給一個專責團隊負責, 一條龍地包含從資料庫連接到使用者介面的開發。不同團隊的前端單元會在客戶端的瀏覽器內整合, 構成最終的頁面。用更容易理解的說法, 微前端就像是帶有使用者介面的微服務架構。 聽起來是要每個開發團隊各自為政, 相信有經驗的開發者可能馬上會想到：那採用不同的技術怎麼整合？會不會有效能瓶頸？類似的功能應該很容易重複開發吧？後端伺服器要各自架設？版本控制要各自維護？各做各的那介面怎麼統一？ 微前端架構當然不可能毫無缺點, 以團隊的角度, 程式碼或資源的冗餘自然是無可避免, 不過只要配套機制運作得當, 所帶來的可擴展性、靈活性，仍然是利大於弊。本書就要教你怎麼無痛建構、轉換到微前端的開發架構。 別擔心要多學新的框架, 雖然確實有一些完全符合微前端概念的框架可以直接套用, 但作者想強調的是微前端架構的概念和選用時機, 若強迫用特定的框架, 很有可能馬上澆熄你的熱情。因此本書會在現有常見的網路技術規範下, 引入微前端的基本機制, 不管你的網站或應用程式採用哪種技術所建構, 幾乎都可以適用。 為了適用各種不同的情境, 作者提供了超過 20 個開發上的使用案例, 協助你將手上專案順利導入微前端的開發架構。除了技術上的交流, 作者也在書中提供不少團隊開發該留意的經驗分享, 界定好開發團隊的責任歸屬, 做好跨團隊間的溝通協調, 讓微前端架構發揮最大價值。 如果你受夠巨無霸一大包的前端單體架構所帶來的諸多困擾, 有了上述這些指引, 現在正是導入微前端架構的好時機, 對於新一代網頁開發人員、架構師或團隊領導者, 相信會帶來非常大的助益。 本書特色: 全書共收錄超過 20 個微前端架構的使用案例, 從簡單的超連結、iframe 和 Ajax 入門, 到較為複雜的 SSI 伺服器端內嵌、ESI、Tailor、Podium、Web Components 以及 app shell、通用渲染等, 並且讓你可以靈活將這些工具和技巧應用於真實情境中。 ● 將不同的應用程式建構為統一的前端頁面。 ● 無縫整合採用各種框架的 JavaScript 程式碼。 ● 各種伺服端與客戶端的整合技術與頁面路由技巧。 ● 協助釐清專案需求, 挑選正確的架構及整合技術。 ● 建構設計系統的樣式庫, 提供一致性的 UI/UX。 ● 提高團隊開發效率並優化專案執行流程。 作者簡介 作者介紹Michael Geers 本書作者 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隨選載入... 內容試閱 我的專案適合何種架構？ 首先要問自己的問題是：專案是要用來達成什麼目的？人們造訪這個網站, 是為了存取內容, 還是要使用某項特定功能？ 【文件─應用程式光譜】 為了讓各位更好想像, 我們來看兩個極端案例： ● 內容取向：想像一個簡單的部落格, 使用者可以瀏覽文章, 並在專門的文章頁面上閱讀完整內文。 ● 行為取向：想像一個線上繪圖程式, 使用者可以到站上以手指繪圖, 並將畫作匯出成圖檔。 內容對第一個網站非常重要, 但第二個網站並不提供內容, 純粹提供功能給使用者。不過在大型專案中, 界線不會如此壁壘分明, 這時文件─應用程式光譜就派上用場了。概念是上述兩個例子分屬光譜的兩端, 此處我們用以下簡圖表示, 只要記得越往左表示網站為內容取向, 適合伺服端渲染技術；越往右表示行為取向, 適合客戶端渲染技術, 位於中間則屬於漸進式應用, 可採用通用渲染技術。 文件(內容取向) ←–––––––––––→ 應用程式(行為取向) 我們來看兩個範例。亞馬遜購物網站位在量表的哪個位置？亞馬遜提供了許多功能, 使用者可以搜尋、排序並過濾產品清單, 還能評價商品、管理退貨、或是和線上客服人員交談。但本質上, 亞馬遜是以內容為取向的網站。一個有助於判別的好問題是：『如果去除掉所有行為, 這個網站是否還有用處？』就亞馬遜網站來說, 答案是肯定的。額外的功能無疑很重要, 但若沒有產品, 這些功能都形同虛設。因此, 我們會把亞馬遜擺在光譜偏左的地方。對於類似的微前端網站, 保險的做法是從伺服器端渲染著手, 再視情況看是否要升級到通用渲染。 接著來看第二個範例。[CodePen.io](http://codepen.io/) 是個線上程式編輯器, 讓網頁開發人員和設計師能即時預覽 HTML、CSS 及 JS 程式碼合併的效果, 勾勒其構想或是尋找潛在錯誤。CodePen 也有一個活躍的線上社群, 許多人會在上頭展示自己的作品並分享程式碼。只要瀏覽 CodePen.io (http://codepen.io/) 上的公開目錄, 你就能找到一大堆振奮人心的新技術。那麼 CodePen 會落在光譜的哪個位置？這個問題較難回答, 因為無論是行為取向的線上編輯器, 還是內容取向的公開目錄, CodePen 在這兩方面都很強。若去掉 CodePen 所有的行為, 線上編輯器就不復存在；假若移除所有內容, 目錄則會不見, 但線上編輯器還會繼續存在, 因此, 我們可能會將 CodePen 定位在光譜中間。如果我們要以微前端架構來重新開發 CodePen, 會編制兩個團隊：編輯器團隊及目錄團隊。編輯團隊會選用客戶端整合, 目錄團隊則可能採用伺服器端路由。這樣便會是一個好起點。 但若要找出最佳的微前端架構, 我們就得進一步分析各種使用案例。我們的某個團隊是否需要整合另一個團隊的內容？使用者在網站上的動線為何？這些都是得繼續深究的問題。 【挑選正確的架構及整合技術】 我們接著來看, 如何以一套具體的方法判斷你的專案需要何種架構及整合方式。你要依序問自己這幾個問題： ● 是否需要高度分離？ ● 需要快速的首次頁面載入嗎？ ● 需要即時使用者回饋嗎？ ...