ExplainThis 全端開發雙週報 #13
你知道 localStorage 但你知道 IndexedDB 嗎、系統設計五大心法 (3) — 非同步、你是否已經在做下一個職級的事 — L3 與 L4 的區別
在本期開始之前，想跟大家分享，ExplainThis 的團隊成員，開始經營自己的社群媒體了。最主要是我們最近重新聚焦 ExplainThis 的定位，未來會更著重在技術分享 (AI、軟體前後端開發)，以及資源分享 (詳見我們最近上線的資源站 PinThis)，所以非相關內容會比較少在 ExplainThis 上露出。
[前端工程] 你知道 localStorage 但你知道 IndexedDB 嗎？
現代瀏覽器中有幾個讓你可以儲存資料的地方，假如打開瀏覽器的開發者工具，可以看到 LocalStorage、SessionStorage、CacheStorage、IndexedDB、Cookies 等。多數前端開發者平常可能比較常用 localStorage，但其實 IndexedDB 也很好用，在這一期讓我們來聊聊 IndexedDB。
其實在全端雙週報 #7 我們就提過 IndexedDB，在那期我們談到專案管理軟體 Linear 透過 IndexedDB 把資料快取在客戶端，當使用者有重新整理頁面時，先查看客戶端快取的資料是否是最新的，如果是的話就不跟伺服器端拿資料，這大幅降低伺服器端的負擔。
你可能會問，localStorage 也可以存東西、當作快取來用，那為何還需要 IndexedDB? 兩者差別在哪? 首先，localStorage 是鍵值對 (key-value pair) 的儲存形式，能夠存的格式只有字串 (string)，所以在存的時候，多半會搭配 JSON.stringify 來用。
而 IndexedDB 則是交易式資料庫 (transactional database)，並透索引 (index) 作為鍵來存取資料，而存的資料格式也不限於字串，基本上 JavaScript 的結構化克隆演算法能處理的物件，都能存在 IndexedDB。此外，IndexedDB 通常會用來處理比較大量的資料。
跟 localStorage 的另一個差別是，IndexedDB 目前在執行面都是非同步 (asynchronous)，換句話說在存取資料時，不會阻塞應用程式的運作。而因為是交易式資料庫，即使是非同步，IndexedDB 也能確保資料的完整性，在寫入資料要不就全部成功，要不就整個全部失敗，不會有部分存成功、部分失敗的狀況。
看完上面的比較，大概可以歸結出，IndexedDB 是個非同步、可以拿來存比較大量資料的瀏覽器儲存空間。那具體他可以拿來做什麼呢? 如先前提到 Linear 用 IndexedDB 做快取，用 IndexedDB 的一個好處是，在離線的時候 (或是使用者的網路斷掉)，仍可以從 IndexedDB 拿資料，在技術上，我們會稱這個為 persistent storing，舉例來說，TanStack Query 有提供 persistQueryClient 可以搭配瀏覽器的儲存機制，來做離線時的快取，提供更好的離線使用體驗。
如果大家想試試看 IndexedDB，可以參考 Google web.dev 的這一篇使用說明 [連結]。不過實務上使用起來還是比較麻煩一點，因此更推薦直接用開源專案 localForage [連結]，這個開源專案額外做一層封裝，把原本比較麻煩使用的 IndexedDB 或 WebSQL，變得可以像 localStorage 一樣簡單操作。
[後端與系統設計] 系統設計五大心法 (3) — 非同步
在前兩期的雙週報，我們分別談了均衡負載 (load balancing)、快取 (cache) 這兩個系統設計心法，在這一期我們將進一步談第三個心法 — 非同步 (asynchronous)。
在系統與程式設計中，當發起某個請求或操作時，可以是同步 (synchronous) 也可以是非同步 (asynchronous) 進行。如果是同步的方式，該直到操作完成，操作會阻塞其他部分的進行。反之，如果選擇非同步的方式，就不需用等該操作完成，也可以避免阻塞的問題。
在討論非同步前，有兩個概念要先釐清，一個是編排 (orchestration)，意即依賴某個中樞的指揮，來驅動整個系統的流程；另一個是協同 (choreography)，意即定義好系統中各個部分的職責，但具體要怎麼運行，則由該部分自行負責。
如果選擇編排的方式，可能遇到的問題會是，當中樞節點出問題，需要有相對應的處理機制，不然會導致整個系統的運作出問題；而選擇用協同的形式，雖然可以有效把各部分與中樞解耦，但是需要有一個額外的系統來監控，確保每個部分的運作都是良好的。從系統的角度來看，除非是關鍵的請求，不然現在業界會更偏向協同的模式。
從協同的角度進一步討論，最常見的非同步模式，就是透過消息對列 (message queue)，下圖是截自 RabbitMQ 的官方教學，可以看到發送方 (producer) 只需要把消息 (message) 送往消息對列，讓接收方(consumer) 依序從消息對列中取出訊息並處理，透過這種方式達到非同步處理。下面的架構不僅能達到解耦，也可以輕易擴展，只需要在發送方、接收方分別增加機器，就可以擴展。
總的來說，想要讓系統解藕，同時能輕易擴展系統，使用消息對列進行非同步處理，是非常有效的方法。這也是在系統設計與面試時，一定要放在腦中的一個心法。在下一期，我們將進一步介紹下一個心法反單點故障 (SPOF)。
[職涯] 你是否已經在做下一個職級的事? L3 與 L4 的區別
在軟體大廠的升遷中，有件跟我過去以為的很不同的差別處是「假如把現階段職級的事情都做得很好，不代表能升遷到下個職級」。原因其實不難理解，因為能勝任現在的職級，不代表能做好下個職級在做的事。那你可能會問「該如何做才能升到下個職級？」，其實很簡單，就是做下個職級要做的事。唯有當你持續展現出自己有能力做下一個職級在做的事，才會被認定夠格升遷到下一職級。
Meta 主任工程師 Ryan Peterman 先前寫過一系列，談 L3 到 L7 的區別，以及可以如何有效從 L3 一路升遷到 L7。在接下來幾期的全端雙週報，我們將摘要這一系列的升遷內容，與大家一探「想邁進下一個職級」需要做到什麼事。
基本上一般大學與碩士畢業，進到大廠會先從 L3 開始，L3 與 L4 的差異所在，主要是L4 能在較少的指引下，處理更大的守備範圍 (scope)。在大廠很常聽人說 scope，這是很關鍵的一個詞，你的 scope 越大，代表在做職級越高的事。一般來說，L3 能獨立處理個別任務 (2 週內)，而 L4 能獨立處理中到大型功能 (2 個月內)。這兩個等級的工程師通常不需要自己發起項目。通常會由資深工程師 (L5) 設定初步方向，然後把任務交給 L3 / L4 的工程師。
L4 工程師需要負責完整的功能，所以被期望要做到專案管理 (project management)。沒錯，工程師也要有專案管理能力，這是很多工程師在職涯初期缺乏的意識。所謂專案管理，是指能將專案拆解成多個子任務，並設定合理的時程，並時時與利害關係人更新進度。
從技術與工程的角度來看，L3 和 L4 工程師都會被預期能交付高品質、經過充分測試的程式碼。但兩者最大的差異是，L4 工程師會被預期主動改進程式碼庫。舉例來說，主動優化程式碼、清理與重構程式碼。以及在程式碼審查 (code review) 有大量貢獻。此外，L4 工程師也會被預期要主動排解線上問題，以及參與輪班 (oncall rotation)。L4 工程師也需要在測試、監控上有所貢獻，來確保程式碼庫的健康。
特別注意，上面提到的事情，不是說 L3 工程師就不用做，而是 L3 工程師不會被預期獨立完成，而是會在有引導與協助下完成。但 L4 工程師則是被預期在沒有引導與協助的狀況下，也能主動提議並這些事。
以上摘要了 L3 與 L4 工程師的差別，下一期我們會摘要假如想從 L3 晉升到 L4，可以具體做些什麼來達成。
本期推薦
React 的 RSC 推出已經一陣子了，但還是許多人沒能掌握 RSC 的概念。最近看到一個開源專案，很清楚說明 RSC 的概念，推薦大家讀讀 [連結]
上面有提到的 TanStack Query 推出 v5 版本了。多了許多新功能外，也優化了過去一些 API，假如有用 TanStack Query 的人，記得去升版 [連結]
LinkedIn 首席工程師 Max Kanat-Alexander 當年還在 Google 時，有寫一篇透過正向布林判斷，來提高程式碼可讀性的文章。我們將它摘要成中文，推薦給想提高程式碼可讀性的人一讀 [連結]
Next.js 最近分享了一篇他們如何優化 import 的效能，寫得淺顯易懂，推薦對效能優化感興趣的人一讀 [連結]。另外，下週將迎來每年一度的 Next Conf，假如還沒報名的人，可以報名追一下線上直播 [連結]
ByteByteGo 宣布開源學習教材 System Design 101，開源後成為昨天 GitHub 星星數飆升最快的開源專案。因為能把複雜的系統設計，用很清楚的圖示、白話的說明，闡述地讓人很好懂，ByteByteGo 的 YouTube 頻道跟電子報，都超過五十萬訂閱者 (很難想像吧，系統設計這種硬知識，既然能做到那麼多訂閱人數)。想提升系統設計能力的人，千萬別錯過這個開源專案 [連結]
自從 ChatGPT 帶起的生成式 AI 浪潮後，從技術的角度，深入淺出地介紹 GPT，非常推薦對背後有興趣的人一讀 [連結]
之前提過，我們認為未來的全端工程師都要具備 AI Engineering 的能力。上週 AI Engineer Summit 沒跟到的人，別錯過直播回放 [連結]。另外假如想了解這塊的技能樹，可以上該組織彙整的 AI Engineer 工作列表看看 [連結]。
感謝閱讀至此的你，如果你喜歡 ExplainThis 雙週報，還請多推薦給身旁的朋友 🙂
另外，最近 ExplainThis 團隊開始籌劃一些進階學習資源。如果你有軟體工程求職與進修相關需求，歡迎填寫問卷讓我們更了解你的需求，以規劃更好的學習資源 [問卷在此]