雜談系列 — Web Frontend Infra
前陣子無意間逛到字節跳動 (ByteDance) 這間公司有一個十分吸引我的 team — Web Infrastructure Team。該團隊的目標在於提供可複用的技術解決方案，同時打造開放的技術生態，推動業界前端技術的發展。目前該團隊主要在研究的領域有 Frontend Architecture、Low Code、Serverless、跨平台開發、Node.js Infrastructure…等等，看起來該團隊的 Web 開發者的工作內容應該跟一般企業的 Web Developer 的工作內容有不小的差異（雙眼發亮🤩）。
今天這篇文章就來隨意聊聊該團隊的其中一項負責領域 — Web Frontend Infra。
什麼是 Web Frontend Infra ?
必須在一開始就告訴各位，通常當企業到達一定的規模，才有可能獨立出一個團隊來負責 frontend 的 infrastructure，因為它其實需要付出一定的人力與金錢成本，也有它的 downside。不過反過來說並不代表沒有獨立出一個專門的 team，就等於沒有做 frontend infra 相關的工作，待會提到的內容各位讀者可能就曾在工作上處理過，只是會相對零碎與分散罷了。
想像一下如果公司只需要開發一個專案
想當然這是一個非常單純的狀況，不管是技術選型、dependency、程式碼品質、開發流程…等等，都非常的直觀，如果出現了 breaking bug 就趕緊修復它就沒問題了，整個產品的進展也會非常的快速。
不過…通常一個企業應該會有非常多的專案，除了對外發布的產品以外，也會有給內部使用的系統。
這時候要面對多個專案時要怎麼辦？
我們當然可以仿造只有一個專案時的方式，從頭打造每一個專案，不過這時候你會發現一個嚴重的問題：
我們違反了 DRY (Don’t Repeat Yourself)原則，一直在做重複的事情。
這時候 Frontend Infra 這個概念就可以派上用場。
1. Boilerplate
通常在專案的最初期會需要選擇適合這個專案需求的 tech stack，例如要使用 React 還是 Vue ? 需不需要採用 SSR 的框架例如 Next.js 或是 Nuxt.js ? 在決定要使用的技術後，我們可以選擇從頭開始建立開發的環境，例如一個一個安裝需要使用的套件，從頭開始撰寫 linting 的 rule config，不過為了節省時間，我們也可以選擇使用別人寫好的 boilerplate template，例如 create-react-app 或者 Vue Cli，基本上只要在 terminal 下幾行指令就可以快速建構出架構算蠻完整的專案。不過這些由官方提供的 template 有時候並沒辦法完全符合企業所想要複用的功能，因此有些公司會選擇建構自己的 template，來達成更客製化的需求。
使用 template 的好處是可以更快速的建立專案環境，不過它仍舊有一些成本在，例如維護 template 的成本、依賴 template 的情況下比較難導入新技術（例如原本的 template 已經整合了 Redux 來處理 state management，這時候如果想要更換其他的 state management 套件會需要花費額外的工）…等等，因此在使用 template 前同樣需要謹慎評估一下。
2. Sharing Code
當我們在開發上累積比較多經驗後，應該都會理解共享程式碼以避免重複撰寫相同邏輯的概念，也就是所謂的 Sharing Code。而 Sharing Code 其實有非常多種方式，小至把共用的 util functions 拆分到其他檔案，大至如果要在不同的專案間共享程式碼時，可以考慮使用 public 或是 private 的 npm 來管理，又或是在 monorepo 架構下可以拆分成獨立的 package 來供 repo 中的不同專案使用。
當然幾乎任何方法的背後都帶著風險成本，如果只有一個專案，要修改 code 其實相當方便，不用怕去影響到其他專案，不過如果是在不同專案間共用程式碼，就必須用更嚴格的標準確保程式碼的品質，同時讓程式碼更具備彈性與可重用性，在測試上也必須變的更加強健。因此就算開發一樣的功能，要思考重用性就會讓開發與維護的成本增加許多。另外版本控制也會是一項難題，在不是使用 monorepo 而是 private npm 的狀況，要如何確保每個專案都能盡量跟到 Sharing Code 最新的版本且不能造成毀滅性的 breaking change，是個耗廢心力的難題。
3. Design System
現代的前端開發主要都是以元件化開發為主，你一定曾經遇過在不同的專案中需要使用功能與樣式都差不多的元件（例如 button），這時候你可能會需要可以「Sharing Design」，而 Design System 就是常見的 solution。
（想更深入了解 Design System 的讀者可以參考朋友 Lichin 推出的線上課程。）
而前端開發者可以進一步依照 Design System 實作出 component library，可以依照需求使用 Vue、React，又或者是你有跨框架共用的需求，也可以考慮使用 Web Component 來實作。這其實也算是一種「Sharing Code 」的方式，所以同樣會具有第二點 Sharing Code 的優缺點，不過它也帶來一些額外的限制，例如更嚴格的「設計」準則、比較缺失彈性的樣式設計風格…等等。
4. Unified CI/CD Infra
專案在完成開發後通常會需要經過 building 與 testing 來驗證程式碼的品質與正確性，在經過嚴格的檢驗後才能被 deploy 上線，而通常這些步驟都會透過 CI/CD pipeline 自動化。在擁有多個專案的情況下，為每個專案獨自建立一個 CI/CD pipeline 當然是一個選擇（目前待過的公司也都是這樣用），不過也有另一種方式是建立一個 Unified CI/CD Infra，讓各專案的開發者可以不用花太多工在建立 pipeline 上，而由 Infra 團隊負責這些 pipeline 的建立與維護。
採用 unified infra 的風險大概就是 reliability 了，統一管理 pipeline 其實也帶出 single point of failure 的風險，萬一今天 infra 炸掉了可能會阻礙每個專案開發或發佈的流程。
5. Deploying & Serving
經過 CI/CD 的驗證後網站最終就可以被 host 上線啦！我們當然不希望自己租一台主機再把網站相關檔案搬過去上線（可以，只是很麻煩），更何況還要設置 CDN 等等機制，目前來說最方便的方式應該就是尋求雲端解決方案了(Cloud)，這種方式的風險無疑就是雲端服務商的可靠性，萬一今天雲端服務商出事了，連帶的可能會影響到底下千千萬萬個服務。
6. Monitoring
以 Frontend 的專案來說一般會搭配 Sentry 或是 Google Analytics、Google Search Console 等可以觀測錯誤、使用者流量、Web Vitals…等等指標的 tracking system，較容易找出網站可以加強或修改的地方。
關於 Web Frontend Infra 的小結論
Web Frontend Infra 的本質其實跟我們常在古裝劇看到的兄弟結義戲碼非常相似：「不求同年同月同日生，但求同年同月同日死！」每個專案的建置時間是不同的，但因為底層採用了相同的 Infra，基本上要死就會一起死，要活就會一起活。
在沒有 Frontend Infra 的情況下，專案看似可以快速推進，不過長遠來看卻是緩慢的，當公司慢慢變得成熟專案越來越多的情況下，會出現一直重複造輪子的問題，程式碼的品質也會隨著專案數量變多而產生分歧。
有了 Frontend Infra 以後，長期來看會推進的比較快，程式碼的品質也會比較好，不過缺點是需要比較多的人力與金錢成本去做這些事，因此比較適合規模比較大的企業採用而非新創的企業。
前端開發者的角色多樣性
我在去年 JSDC 分享的主題「從前端邁向全端 — 前端開發者不該錯過的 Serverless 技術」中就有提到我覺得現今前端的角色因為 Serverless 的盛行而有了往全端開發者邁進的趨勢。回到今天的主題 Frontend Infra，再仔細看看 ByteDance Web Infra 團隊的求職需求，我們可以發現除了 Serverless 以外，它們對於前端開發者的要求還有對 compiler、bundler 的了解（可能會需要去改一些客製化的需求），甚至對於 Node.js 的 Infrastructure 也要有一定的掌握度，可以看出前端開發者的角色多樣性，除了偏向全端的前端開發者以外，也有走向更底層 Infra 端的前端開發者。
結論
透過一篇簡短的文章大概介紹了所謂的 Web Frontend Infra，而一再強調的是這種架構比較適合規模與資金都比較足夠的大企業採用。對我自己而言，我認為最值得各位讀者去了解的是前端開發者的角色多樣性，也許你平常是個一直在切畫面的前端開發者，不過其實前端在未來有了越來越多的發展空間，不管是走向後端或是走向更底層的 Infra、建置工具型專案，當讓前端開發者可以產生更多價值，一起期待吧！
