傳統開發模式
以往的開發模式是採用Monolithic的單體式架構
你可以想像成，把很多種功能都寫在一起的概念
以一個電商平台來說，功能可能包含列表, 刊登, 購物狀態……
這些商務邏輯也都是綁在一起的，每一次的sprint也都是會一起部署上去
因此這樣的設計有個很明顯的缺點：面對大量需求的來臨時，容易不堪負荷
擴展性和開發效率並不高，再遭一點的狀況就是改A壞B不斷的發生，甚至無限循環
這在產品從中型邁向大型專案時，時常發生
也因為這樣，micro service提出了解決方案
微服務的開發
micro service將原本的大型專案拆分成很多個小服務應用
每個服務都有各自的Server與database
以一個電商平台來說，功能可能包含列表, 刊登, 購物狀態……
那麼這些服務原本寫在一起會變成拆成三個。
這樣的好處是，部署和開發都是各自獨立的，擴展性也較傳統開發模式還好
因此micro service也在近年開始流行了起來
微服務有缺點嗎
任何事都有一體兩面，也沒有絕對的好壞
微服務把彼此都拆分開來，但是某些情境還是會有彼此溝通的需求
此外設計時也要考量到設計架構的議題
可以應用在前端嗎
這是最近討論逐漸熱議的題目，無論是前後端在協作總是會遇到一些問題
以往在協作開發前端的時候，需要撰寫程式操縱DOM事件
但是很容易遇到協作conflict的問題，也因此component-based設計的React被大家所矚目
開發前端只要專注在調整元件設計就可以避免很多協助上的議題
但是這樣子還不夠，協作上還是會遇到部署與開發的議題
而且如果產品不小心有一個漏洞在線上，會變成整個服務無法使用
因此把前端產品拆分成很多種微服務也是一個方式
Micro Frontend的例子
其實我們無形之中已經在用類似Micro Frontend的事情了
只是我們並沒有own這些產生而已，我可以分享我和其他夥伴協作的例子
今天假設我是一個start-up team，但是我想要快速產出一個MVP來給團隊Demo使用
我們時間不多，但是其他平台其實已經做好現成的服務可以使用了
網站的http request
假設一個landing page，功能用到
- /items/123
- /about/123
- /gallery/123
如果其中一個功能壞掉了，你覺得這個網站還可以使用嗎？
https://www.youtube.com/watch?v=Kphwg2IsJfA
https://github.com/willmendesneto/micro-frontend-pages
Comment
