我總是想知道大型Web應用程序是如何建造的!我發現了秘密的秘密，它成為我的激情。經歷在規模上使用微型前端的優勢和痛苦后，我決定記錄這段旅程并分享一些“最佳實踐”。

這是在設計遵循微前端模式的應用程序時的最佳實踐的自由練習列表。應檢查每個“規則”，其福利/缺陷針對您的特定用例評估。

[[393246]]

微前端之間的零耦合

為了實現這種架構的好處，應盡可能避免意外耦合;這將解鎖微前端模式必須提供的靈活性和可擴展性以及通過允許占用申請部分的升級或將來的完整重寫來替換您的應用程序的未來證明。

每個微前端應該能夠在隔離或容器應用中呈現。所需的數據應由每個微前端加載并避免數據瀑布。

做✅：

• 可以在不影響其他微前端的情況下交換的共享庫。
• 加載所需的所有數據呈現。

不要❌：

• 在不同的微前端具有集中存儲/共享數據。
• 共享積極開發的庫。

單獨的代碼基礎

每個微前端都應具有自己的代碼庫，并且選擇的版本控制不應對項目開發或部署的方式產生任何影響。在單一的單一或單獨的存儲庫下擁有所有項目都很好。

做✅：

• 使用單一代碼倉 monorepos。
• 使用單個 repos。

每個微前端應獨立部署

每個微型前端都有它自己的CI / CD管道，并且能夠在沒有其他微前端的任何依賴項的情況下部署到生產。應該避免的常見的反模式是“地獄的部署隊列”，其中不同的微前端如此緊密地耦合，它們需要以特定順序部署，以避免打破應用程序。

做✅：

• 具有單獨的CI / CD管道。
• 按需發布。

不要❌：

• 有發布時間表。
• 具有允許以前版本的增量/順序部署。

微前端應獨立測試

因為需要單獨的微前端以及容器應用程序內部呈現，因此還可以使用單位和整個方案的集成測試測試它們是有意義的。

做✅：

• 為隔離的每個微前端渲染具有單位和集成測試。
• 在容器應用程序中運行微前端渲染的集成測試作為端到端測試的一部分。

微前端應該是有版本的

當一個新的微前端被部署到生產時，不應刪除以前的版本，并且應該使用語義版本或類似的版本號標記新版本。由容器應用程序決定要使用(管理)的特定微前端或始終使用最新版本(Evergreen)的特定版本。

做✅：

• 使用語義版本化。
• 使用特定版本或“最新”。

不要❌：

• 需要全局部署更改版本。
• 刪除以前的版本。

最小的溝通

微前端之間的通信應盡可能最小，簡單，避免盡可能多的全球狀態和框架特定的解決方案。

如果兩個或更多的微前端共享大量消息以提供其最小功能，它們可能太緊密耦合，并且它們可以共享類似的足夠的目的，即它們應該被認為將它們集成到一個中。

做✅：

• 保持信息小而簡單。
• 如果可能的話，避免有狀態和通信框架。

不要❌：

• 股東。
• 有不必要的溝通。

CSS應該是范圍

來自一個微前端的CSS不應影響其它微前端。

做✅：

• 為您的CSS定義范圍。
• 使用CSS-IN-JS或命名法庫(如CSS模塊)。

不要❌：

• 使用全局CSS。

最終建議書

做✅：

• 嘗試創建自治團隊。
• 嘗試安排圍繞業務功能的微前端。
• 可重用性是一個很好的“副作用”而不是目標。

不要❌：

• 不要強制這種架構風格，因為它是“新”。
• 您不需要多個JavaScript框架。
• 您不需要“微前端框架”。
• 微前端不必是“Micro”。

原文鏈接：https://medium.com/swlh/rules-of-micro-frontends-7b96c10dde9