使用微前端，快速響應業務需求。
在街口前端，微前端是我孕育的其中一個方案，也是我前期花最多時間思考和實作的專案之一。
然而在當時這名詞頗為新穎，但概念上不難懂，事實上，很多公司都已經用「自己」的方法來實踐，例如最常見的方法就是：Iframe 和 Nginx 分流。
猜出來了吧，所謂微前端，就是把原本的一大包bundle分割成數個「網站」然後再由一個「網站」把他們統整在一起。倘若你對微前端有更詳盡深入的解說，恭喜你，可以略過這一段，但假設你對這個毫無概念，我剛剛的說法，相信是你理解它最簡短的說法。
它，不是一個框架，而是一個架構方法。
WHY
為什麼我需要把一件「簡單」的事情弄得複雜呢？
對於前端而言，一個SPA就可以解決全部需求，為什麼我們需要這樣做呢？原因很簡單。
- 傳統的SPA建站方式具備歷史成本（技術債）
- 擴建難度會隨著時間越久，成本約高。
- 牽一髮，而動全身，改了一行神奇代碼之後，全站奔潰。
光是這幾個原因，就無法做一個「快速回應」這個需求。
HOW：Domain base
既然如此，那我們就著手進行微前端的計畫，而這計畫有幾個重點目標和階段。
- 快速產生微前端的方法，類似CRA的CLI
- Domain base 做為APP的最小單位。
- 一套會員管理機制，並可控制會員和APP的權限。
而第一次實踐微前端的場景便是後台，總所周知，後台在前端上是一個既簡單又複雜的工作，簡單的是因為它單調或重複性高的畫面，困難的是它複雜的資料流和環境，所以一般上，後台的前端工程，從來都不會有人「升級」，大部分人，都採用「重做比較快」的策略。
可能大部分工程師會在這個時候跳出來說，是因為需求變化太快，所以不得不做出妥協，在所難免，那我們應該怎麼做，才可以讓專案進行下去，又可以不斷修正和擴建，而且它不是技術債呢？就以第一張圖舉例。
- 這裡可以很清楚看到，每一次（每一個）功能都是完全獨立分開
- 任何一次新業務需求，都會按照這個模式新增
- 基於他們的都是獨立的專案，所以工程師並不需要完全由同一個人處理。
- 每次更版、更新、替換、修改、都大大降低導致整個網站不可用的風險。
目標：制訂一個標準規範，它可以是任何形式的規範，而我這裡的實作是基於 Single-spa.js，所以最後的基本規則如下：
- 每個後台是一個 Root config
- 每個選項（domain、功能）是一個 app
- Root 利用import map 決定了登入者可以使用什麼APP，
- 每個APP是一個CDN bundle js 檔案。
HOW：搭建環境
這是最開始的開發流程，CLI 還沒做好之前，我們用複製貼上的取代，總而言之就是有一個存放大量備用模板的地方。
因為我們前期做了很多準備，所以在遇到新需求時，只需要稍作調整，就可以馬上生產出新的APP整合到Root config上。
光是快速啟動是不足以應付，離完成還有一段距離，所以還需要其他輔助工具加入這個搭建系統。
如此一來，只需要時間累積，每個區塊的基礎就會沈澱出更有用的東西，因為一開始的設計都基於假設上，事實上業務需求都有很大可能的變動，做為前端，你懂的。
假設情況樂觀，最終我們只需要操控輸入的參數設定，就可以控制最後產出的APP，或至少可以減少百分之50的實作時間。
THEN：Low-Code and No-Code
基於這樣的大前提，我們在實作上，會往更多Low-code的方向進行，要做到這幾點，我們需要做好基礎工作，包括：
- 任意介面結構化。
- 自動化搭建能力。
- 系統化的素材（模組） 庫。
這樣甚至我們可以搭建一個後台，專門產生數據（就是上圖紅色那一個區塊），就可以完成端對端的發布，完全不需要經過RD，應該沒有什麼比不需要開發來的更快的回應業務需求了。
