預測微前端的未來 - luca

微前端的通訊
當我們在同一個檢視中擁有多個微前端時，在某些時候它們需要相互溝通。
在我為設計微前端而建立的心理模型中，鼓勵使用釋出-訂閱模式在微前端之間進行通訊，以執行微前端之間的邊界，避免或至少減少設計時的耦合性，從而導致更多的自主團隊。
為了在技術上實現這種模式，有幾種選擇，如自定義事件、事件發射器庫，甚至是反應式流。
在過去的幾個月裡，出現了一個重要的需求，我在開始的時候並沒有太強調，可能是因為我把它當成了理所當然，但這絕對是需要注意的。
就像後臺的事件驅動架構一樣，對事件有一個清晰的模式將有助於避免在整合階段出現錯誤。此外，模式還可以讓那些不直接從事程式碼庫工作的技術人員清楚地瞭解特定應用程式內部發生了什麼。
我在我關注的眾多Slack頻道中發現了這個事件匯流排庫，它絕對有助於在鬆散耦合的元素（微前端，但不限於此）之間實現更有條理的通訊。
考慮到微前端是一個分散式架構，需要有一個更正式的API或事件管理。
API或事件是團隊互動的方式，不僅僅是在微前端。
我們必須明白，這些做法不僅僅是幫助開發者在傳送事件時避免錯誤，而且還能促進團隊之間的討論，提供清晰的意圖。
我希望在未來，當我們有大量使用松耦合通訊策略的大型應用時，會有更多的努力來簡化開發者的體驗。
如果有一個事件登錄檔，在我們每次開發新的微前端之間的互動時都能參考，那該有多好？
 

伺服器端渲染（SSR）
伺服器端渲染架構是過去幾個月中創新較多的，想想Next.js或者React 18背後的團隊對伺服器元件的投資。
我們在微型前端也有一些有趣的解決方案，比如Next.js的 module federation for Next.js, Piral, TailorX, ILC 等等。
對於SSR微前端的應用，我們應該開始更深入地研究一些課題。
這些是我到目前為止發現的差距：

• 微前端的發現：就像微服務的服務發現模式，但應用於前端。使用這種模式，我們可以動態地組成微前端，而不需要對系統中的端點有任何靜態的參考。
  想象一下，一個微前端基礎設施自我註冊到一個發現服務，一個UI組合器從發現服務中檢索微前端，而不是與微前端本身進行點對點的連線。
• 雲端計算上的參考架構：在如何使用流行的雲供應商構建SSR微前端架構方面，缺乏指導。這是一個可以較快解決的摩擦點，我希望能儘可能地提供幫助。
• 利用微前端的無伺服器正規化。我相信無伺服器可以提供一個很好的開發速度，將基礎設施管理委託給雲供應商。同時，我們必須轉變思路，瞭解我們應該為微前端等特定工作負載利用哪些服務。
  例如，我認為使用像AWS Step Functions這樣的服務來簡化微前端的建立是有價值的，因為它提供了與整個AWS生態系統的巨大整合。這使我們能夠接受一種低程式碼模式，從長遠來看，這將簡化維護。
  這是我們可以在雲上使用的許多模式之一，但用微前端探索這些模式可能是非常迷人的（至少對我來說是這樣）。
• 一種框架無關的React伺服器元件方法：當後端資料發生變化時，有一種機制可以使用SSR原子化地重新載入檢視的一部分，並與客戶端微前端無縫整合。這將允許混合架構混合CSR和SSR，為每個微前端使用正確的方法。也許我們今天就可以建立這樣的機制，但像React 18那樣有一個光滑的實現將是最終的目標。

區域性水化hydration
效能是每個前端應用程式的關鍵，包括微型前端的。
我已經很久沒有聽說過 "島嶼架構 "的概念了，然而，我相信最終這種架構由於其原則和特點，可能屬於微前端的範疇。
島嶼架構引入的有趣技術是透過利用部分水化來提高我們伺服器端渲染應用程式的效能。
簡而言之，不是對整個頁面進行水化，而是隻對使用者可見的 "島嶼 "立即進行水化，其他的將在使用者看到它們時進行水化。
區域性水化並不是一個新的技術，從2019年開始就有了（如果我記得很清楚的話），但是我沒有在微前端應用中看到任何關於這個技術的參考。考慮到微前端的性質和部分水化的工作方式，我相信這種技術應該會得到更多的青睞，以進一步最佳化我們的SSR微前端應用。
 

微型前端和邊緣計算
當我們談論邊緣的微前端時，我們通常會想到Edge-Side Includes（ESI）標記語言。
這次我指的是許多CDN正在提供的計算能力，如邊緣的AWS Lambda或Cloudflare workers。
邊緣技術正在快速發展，因此部分應用可以被移到邊緣，改善我們解決方案的延遲和可擴充套件性。
然而，在許多網路應用中，我們不能只考慮使用多個微前端生成HTML頁面的計算工作，我們還需要考慮整個應用的複雜性。
計算通常是當今 "最容易 "解決的問題，當涉及到資料引力（資料庫、多區域資料複製、全球基礎設施的寫與讀、資料複製延遲......），或認證時，通常是集中在雲基礎設施的特定區域或甚至是內部的資料中心，並有良好的安全性。
的確，SSR微前端應用可以從邊緣計算中受益，但它們需要訪問大量的其他資源（資料、認證、快取......），這些資源在邊緣還不能完全使用。
我們不能真正考慮使用邊緣的全部力量，除非我們有一個非常好的封裝的工作負載，不需要任何這些外部依賴性。
我相信在未來我們會更多地採用邊緣技術，但同時我認為我們必須更好地理解邊緣技術在哪些方面可以對我們的工作負載產生真正的影響，而不僅僅是因為與邊緣節點一起工作是 "很酷 "的（有炒作驅動的開發嗎？
在我看來，在不久的將來，邊緣計算將與微型前端有很大的關係，特別是對於提高應用程式的效能，但它並不像現在看起來那麼簡單。
 

部署
在微服務中，有一套統一的做法來降低新的微服務版本的部署風險，如功能標誌、藍綠部署和金絲雀釋出。
在過去的12個月中，我沒有看到在微前端中實施類似的做法，這部分是來自於功能標誌，它看起來是許多團隊的知名模式。
我相信一個能給開發團隊帶來信心的部署策略是必須的。
在一個分散式系統中，持續部署往往是一個現實，我們必須為開發人員創造一個安全網，使他們能夠快速迭代，將他們的程式碼從他們的膝上型電腦轉移到生產環境中，而不會有引入所有使用者體驗的錯誤的風險。
對於SSR微前端，我們可以很容易地重用現有的工具和實踐，利用這些機制之一來發布我們的基礎設施，儘管，這些策略往往不被客戶端渲染微前端應用程式所接受。
我們有幾種方法可以實現它們，客戶端、伺服器端甚至是邊緣。
我的建議是儘快實施這些策略中的一種，因為它們可以為你的團隊創造一個更安全的環境，其結果可能會讓你吃驚......在積極方面
 

路由
與部署策略嚴格相關的是，客戶端渲染的微前端應用程式缺乏一個堅實的路由策略。
所有的實現都在使用我們用來實現單體架構的路由庫。
相反，我相信我們可以做得比這更好!
當我們把路由庫和前面描述的部署策略混合在一起時，我們可以有一個非常聰明的路由，考慮到較新的微前端版本，不同的環境，甚至是不同的使用者角色。
我們也可以有一些工具，逐漸增加對版本的流量，並以同樣的方式執行回滾。
例如，當我們在AWS中開發容器或無伺服器工作負載時，我們可以透過幾行配置輕鬆設定我們喜歡的部署策略。
應用程式外殼中的路由可以透過外部JSON輕鬆協調，提供不同的可能性，而不需要將這些資訊整合到應用邏輯中。
最後，當這種靜態的JSON與部署邏輯相結合時，我相信這種組合可以帶來很多價值，減少新版本的風險，並允許根據你的企業想要實現的任何邏輯進行動態配置。
路由和部署絕對是我感興趣的領域。在接下來的幾個月裡，我將投入時間來消除無差別的繁重工作，讓團隊能夠更好地控制他們的部署和路由。我希望我能夠儘早分享我的工作內容，因為工作組對這兩個主題非常興奮 
 

微前臺的管理
我沒有探索（還沒有）這個領域，但我有一個工具清單，可以嘗試瞭解微前端的優點和缺點。
我的重點將主要放在monorepo上，因為我相信對於poly-repo，我們不需要額外的工具來管理程式碼，就像在同一個倉庫中有多個獨立專案時一樣。
目前，這些工具引起了我的注意：

• Turborepo
• PNPM
• Projen

總結
正如你所看到的，在微前端生態系統中仍有很多地方需要覆蓋，但我們在過去幾年中取得了巨大的進步。
對我來說，這是一個超級令人興奮的機會，可以為一個 "年輕 "的架構塑造許多改進的領域，在全球企業組織中獲得成功。
我相信還有更多的東西需要發現，我希望這種快速的採用會給分散式UI架構中哪些是可行的，哪些是不可行的帶來新的見解。