ExplainThis 全端開發雙週報 #16

淺談 pnpm、從 API Gateway 看前端與後端、如何加速成為 L5 資深工程師

Hi，歡迎閱讀最新一期的 ExplainThis 全端雙週報，我是雙週報主筆 Li [IG 連結]。在這一期開始前想跟大家分享 ExplainThis 另一個共同創辦人 Lynn，最近在她的 IG 開始了年末 40 天反思活動。

這個反思活動是源自 Obsidian 執行長 Steph Ango 在七年前曾經分享了 40 個值得在年末與自己對話的問題。有興趣一起反思過去一年的朋友，可以在這一個月關注 Lynn 的 IG 限時動態 [IG 連結]。

最後，ExplainThis 到今年底的諮詢與模擬面試已經額滿，假如明年的年後有預計轉職，可以先預約一月與二月的時段 [連結]。

講完了 ExplainThis 的近期更新，接著讓我們進到本期的正式內容吧 🙂

[前端工程] 淺談 pnpm

身為前端開發者，你大概一定聽過 npm 這個套件管理工具，可能也聽過社群許多人會用的 yarn，以及過去兩年熱門的 bun。但其實還有一個叫 pnpm 的套件管理工具，是在 bun 出來之前，受到許多開發團隊親賴的。這一期我們來聊聊 pnpm。

在 pnpm 的官網中是用 Fast, disk space efficient package manager 來介紹 pnpm 的。可以看到，這邊強調的是兩個特點，一個是在時間維度上快，另一個是在空間維度上有效率。

先來講快這一點，之所以 pnpm 比起 npm 或者 yarn 來得快，是因為 pnpm 在設計上，共享了依賴，這可以避免重複下載何解壓縮已經被處理過的套件，因此在多個不同套件都有相同依賴的狀況下，pnpm 會快很多。除此之外，pnpm 也做了本地快取，這能夠減少對網路的依賴；在有快取的狀況下，即使網路速度慢，如果命中本地快取，一樣可以快速完成套件安裝。

接著來講空間上的節省，因為 pnpm 有全局儲存 (global store) 的機制，這能有效避免重複儲存相同的依賴，因此如果你使用的多個套件有重複依賴，最終這些相同的依賴，都只會在硬碟中存一次，這大幅度降低依賴在硬碟中佔據的空間。對比起來，npm 與 yarn 都會在每一個不同的專案複製一份，因此會佔用比較多空間。

要理解 pnpm 在依賴結構設計的巧妙上，我們要先懂 Node.js 是如何找到某個依賴的

• 首先 Node.js 會先找自己的模組 (例如 `fs`)，這部分不需要額外路徑解析

• 如果不是 Node.js 內建模組，它會從 `node_modules` 底下開始找，如果沒有 `node_modules`，則會從目前的檔案目錄中，逐一遍歷直到找到最近的 `node_modules` 然後從中找尋某個模組

• 如果找不到，就會繼續遍歷直到找到，如果遍歷完整個目錄還是找不到，就會拋出錯誤

在 pnpm 的設計下，當 Node.js 要開始查找模組時，在 `node_modules` 底下，大家可能會看到右箭頭的符號，這個右箭頭是指某個連鏈接 (link)，這個鏈接會指向上面有提到的全域儲存 (global store)，所以可以理解成，當 Node 要找該模組時，pnpm 會跟 Node 說去全域的某個位置可以找到。

而這個全域儲存的位置，就是在 `node_modules` 底下的 `.pnpm` 資料夾中，只有在這個資料夾當中的，是真正的檔案，其他的都只是一個指針 (pointer)，會指向這個真正存的地方。這樣一來，就可以避免同樣的依賴被複製一份並且重複存

從 pnpm 的設計可以看到，其實在前端的領域，把資料結構學好，是很有價值的，當換了一種設計，就能大幅度減少使用的空間～

[後端與系統設計] 從 API Gateway 看前端與後端

假如你是從很久以前就開始做開發，可能有經歷過一段人人都是全端工程師的時光，在當時還沒有所謂的前後端分離，基本上請求從客戶端發送來後，伺服器會去處理所有事情，包含跟資料庫打交道，以及把準備好的 HTML 返回給客戶端。在這個架構下，因為所有東西都放在一起，不論是可擴展性或是故障時的隔離都會比較差。

要能比較有效做隔離，以及讓程式比較好維護，後來發展出把不同的應用做拆分。舉例來說，在一個電商的應用情境下，我們可以把使用者放到 `/user`、訂單放到 `/order` 底下、物流放到 `/logistic` 底下，這樣能做到基本的隔離，也可以讓每個應用變得比較單純，也會比較好管理。

但這種做法也有問題，假如這些仍都是放在伺服器端，這樣與客戶端仍是耦合的，這樣要進一步拓展會比較困難。但是如果兩者解耦合，又會導致前端可能需要大量請求多個不同後端 API，才能在前端組成所需的東西，這個問題在 Theo 的這個影片中有很生動的說明

要解決這個問題，BFF 由此而生。所謂的 BFF 就是指 Backend for Frontend，意思是給前端的後端，這邊強調「給前端的」是對比「與前端解耦的」後端。BFF 在做的事情很簡單，就是在前端與不同的後端 RPC 中間多加一層，然後讓這層 BFF 去處理呼叫不同 RPC 來拿到所需的資料或者處理相關邏輯；而前端則不需用在自己呼叫一堆 RPC，可以只呼叫 BFF 就好。

但是這又會出現一個問題，假如 BFF 是為了特定的前端需求而有的後端，那假如是通用的前端需求，例如常見的驗證 (auth)、限流 (rate limiting) 與平衡負載 (load balancing) 等，這不屬於特定的 BFF，但又是每個 BFF 都需要的，這該由誰來處理呢?

在目前業界的普遍做法，是會交由 API Gateway 來處理，所謂的 Gateway 就是一個入口，在實際進到 BFF 前，會需要先經過 API Gateway 這個入口。舉例來說，假如有個沒權限的人想要呼叫某個 BFF，在 API Gateway 就可以先驗證然後擋下來。

當演進到 API Gateway 的出現，上述過程中會發生的各種事就都能被有效解決，而我們可以有個可拓展、解耦，但同時又能為特定前端提供需求的架構。

[職涯] 如何加速成為 L5 資深工程師?

在上一期的雙週報，我們摘要了 Meta 主任工程師 Ryan Peterman 分享的中階與資深工程師差別。在這一期，我們將摘要究竟什麼是 L5 資深工程師的定義。

在多數科技大廠，資深工程師都被歸屬在「終端」職級，意思是當到達資深後，就不再有晉升壓力，雖然你可以繼續往主任工程師、首席工程師等職位邁進，但你也可以選擇一輩子待在資深的職位。

從策略面來看，想要達到資深，需要做到以下幾點：

• 儘快找到資深範疇的項目：你可以積極跟工程經理或技術領導討論，去爭取足夠被認定為資深範疇的項目。一旦確認下該項目後，全神貫注完成它。

• 專注在團隊領導與影響力，對於資深來說，寫程式仍然重要，但不是最重要的事。做能夠展現領導的事，並且實際去影響團隊，會是更重要的 (具體可參考上一期摘要的內容)。

• 讓團隊中的其他成員變更好：尋找能協助提升和指導他人的機會。這些對你晉升到資深至關重要。
  

一般來說，從中階要晉升到資深，時間表會如下：

• 半年內晉升：這通常很難，因為你代表你一加入團隊就馬上發揮團隊級別的領導力。

• 一年完成晉升：這也很不容易，但如果你有足夠野心，也可以把這設為目標。如果你在前半年找到資深範疇的項目，在後半年確保有順利做好，那將可能在一年完成升遷到資深。
  

上面這些聽起來好像很容易，但實際上該怎麼做，Ryan 分享他自己如何在一年半完成升上資深：

• 第一個半年：我的成長之路 H1（L4 超出預期）- 這半年，我完成了讓我晉升到L4的工作流程，並開始了另一個L4項目。我這半年花了很多時間在工程技術上，因為我很享受這個過程。我淘汰了一些沒人願意動手的老舊系統，因為它們既危險又沒什麼影響力。這半年我沒有展現任何L5的行為。

• 第二個半年：當時 Ryan 其實已經在做資深在做的事，包含帶一個 6 個工程師的團隊完成團隊級別的項目，並且指導了一名實習生。但因為那年新冠疫情 Meta 取消該半年的績效考核，所以他沒能獲得被提名升遷的機會

• 第三個半年：第三個半年 Ryan 拿到超乎預期的績效考核，甚至開始做主任工程師 (L6) 在做的事，包含制定了跨年度的技術路徑圖，並帶領另一個團隊含有多名工程師的專案，並且對 Instagram 的影音廣告進行重大的重構。因為在這半年有展現了團隊級別的影響力和領導力，讓 Ryan 能順利升遷到資深。
  

關於升遷到資深的過程，Ryan 提到以下幾個事後回顧覺得特別關鍵的地方：

• 技術領導：如果你已經能到中階工程師 (L4) 的職級，表示你程式已經寫的不錯。而要進一步做到資深，意味著你需要幫助團隊中其他人，也做到同樣的事。

• 全力以赴：Ryan 提到當初自己在每個項目都全力以赴，即使有時感到負荷很大，但全力以赴讓他能在負責的項目，做出高影響力，這也減少晉升時的風險。

• 專注在影響力：全力以赴也需要在對的方向，假如花很多時間在影響力不大的項目，即使全力以赴可能也沒辦法有效升遷。記住，假如某些事情必要做，但是可能本身影響力不大，你可以帶領團隊一起完成，讓你有時間去做範疇更大的項目。

[本期推薦]

• 過去一週在社群上很多人在分享的《An Interactive Guide to CSS Grid》 ，詳細地說明了 CSS 中的 Grid 概念。很多人可能對 Grid 的使用一知半解，很推薦讀這篇 [連結]

• 近期社群中討論度極高的 Vest.js ，讓人可以像寫測試一樣，用宣告式的方式， 去寫表單驗證流程。之前完全沒想過表單驗證可以用這種方式來寫，看到 Vest.js 非常有被啟發到的感覺 [連結]

• 當提起 SSR，你腦中浮現的定義會是什麼? 《從歷史的角度探討多種 SSR（Server-side rendering）》一文帶著讀者從考古的角度，一起理解 SSR 的前世今生，讀起來非常過癮，推薦大家 [連結]

• Amazon 的 技術長 Werner Vogels 每年的年末都會對接下來一年的科技發展做預測，在這週他也分享了對 2024 年度預測 [連結]

• 假如有在做 Web 開發的人，一定對 Google 過去出的節目 HTTP203 不陌生，該節目是九年前 Google 工程師 Jake Archibald 開啟的一個 YouTube 節目，他擅長用輕鬆有趣的方式，講 Web 開發的最新趨勢。在離開 Google 後，Jake Archibald 開了另一個新節目 Off The Main Thread，非常推薦大家去聽 [連結]

• 假如是做前端開發的人，大概都學過 AJAX 這個技術，然後大概聽過當初 Gmail 就是透過 AJAX 技術完全顛覆了傳統前端工程，讓前端頁面不用整個畫面重新渲染也能更新，達到極佳的使用體驗。做這件事的 Paul Buchheit 當初決定要用 JavaScript 寫 Gmail 前端時，他在 Google 內部被無數人勸阻，多數人都覺得這個技術決策糟透了。甚至有位當時的 Google 高管，直接斷言說 Gmail 這產品連百萬用戶都不可能達到 (今天的 Gmail 超過 18 億用戶)。是採用什麼樣的思維模式，讓 Paul Buchheit 即使遭到這樣的批評與挑戰，也願意去嘗試，最終帶來顛覆性的創新? Paul Buchheit 曾經寫過的 6 個預設思維模式 [連結]，讀完後真的覺得很受用

• Flutter 共同創作者 Ian Hickson 離開待了 18 年的 Google，並寫下《Reflecting on 18 years at Google》一文，描述當年在 Google 剛上市後加入的榮景，到 18 年後辭職的今天，Google 如何失去最初的信念與文化，從重視長期用戶價值，轉而重視變成短期利益與股價

• OpenAI 共同創辦人 Greg Brockman 過去曾擔任 Stripe 的 CTO，從傳統軟體工程師，轉向機器學習領域的學習路上，也一度信心低落。他幾年前撰寫了《我如何成為機器學習實踐者 How I became a machine learning practitioner》一文，紀錄了他的心路歷程。我們推薦所有想轉職的人，即使不是要轉去機器學習領域，都很值得花時間讀這篇文章。於是我們決定翻譯成中文跟大家分享