ExplainThis 全端開發雙週報 #7
前端開發時的 JavaScript 的成本考量、 Linear 如何設計高效能同步引擎、後 ChatGPT 時代的新職涯
[前端工程] 前端開發時的 JavaScript 的成本考量
JavaScript 是讓網頁應用程式能夠具有互動性的程式語言，也是前端工程不可或缺的一環，然而過多的 JavaScript 是有成本的。 《The Cost of JavaScript》是前端界很經典的一個演講，講者 Addy Osmani 上個月分享了 2023 年版本的內容。
在談論 JavaScript 前，有個重要的概念需要放在腦中，那就是硬體與網路速度對網頁的影響很大；而在這世界上，多數人仍是使用中低階的裝置，因此同樣的程式在你開發的環境可能跑很快，但這不代表對那些用比較低階裝置的使用者是同樣的速度。這也是為什麼我們要在乎 JavaScript 成本，因為越大包的 JavaScript，載入與執行越慢，在中低階裝置上會特別有感。
從 JavaScript 的角度來看，平常我們在執行 npm install 時，每多裝一個套件，就是多一個成本。要降低成本的一個方式，是拆分程式碼 (code splitting)，把打包出的 JavaScript 拆成多個模組，然後只在需要時加載該模組，這樣可以避免在最開始加載一個大的模組導致時間變長。
近幾年為了加快網頁應用的加載，前端業界開始回歸伺服器端渲染 (SSR)，在伺服器端渲染好 HTML，傳送到客戶端後才加上事件處理器 (又稱為注水 hydration)，這個概念進一步延伸出島嶼架構 (Islands Architecture) 與漸進式注水 (Progressive Hydration)，等減少在最開始一次注水，進而提升速度。同時也有 Qwik 框架提出的 Resumability 概念，只在需要的時候創建事件處理器，確保最少量的 JavaScript。
另外也有許多框架開始推出了「零 JavaScript」的概念，其中包含 React 的 Server Components (RSC)，完全在伺服器端渲染好元件，然後透過串流的方式傳到客戶端，大幅加速了最開始的加載速度。
總結來說，在 2023 年的前端，有非常多過去沒有的創新，能夠協助我們更有效的控管過量的 JavaScript。在演講的最後，Addy Osmani 重述不要把高階裝置與高速網路，視為理所當然；在開發時用中低階的裝置與一般的網速，會更貼近真實的使用狀況。同時他建議每個前端團隊，都要為效能設定目標，並且花時間與精力來確保不會超出設定的目標。
[後端與系統設計] Linear 如何設計高效能同步引擎 (Sync Engine)
Linear 是目前社群中非常受歡迎的專案管理工具，許多公司與團隊過去可能會使用 Jira 等工具，但近幾年陸續出現往 Linear 遷移的現象。原因無他，就是因為 Linear 的效能與使用體驗好非常多。Linear 是如何做到如此高的效能? 在《Scaling the Linear Sync Engine》的演講中，Linear 共同創辦人 Tuomas Artman 分享了他們如何設計高效的同步引擎 (Sync Engine)
在 Linear 的設計中有幾個看點。首先，Linear 善用客戶端的快取 (cache)，他們透過 IndexedDB 把資料快取在客戶端，當使用者有重新整理頁面時，先查看客戶端快取的資料是否是最新的，如果是的話就不跟伺服器端拿資料，這大幅降低伺服器端的負擔。
當客戶端有任何改動時，會立刻更新客戶端的狀態 (optimistic update)，這會讓使用者感到應用程式響應很快；而實際的改動請求，會被放到一個佇列 (queue) 當中，然後發送給伺服器端去處理。透過佇列，如果客戶端在短時間內有大量改動，在佇列中還沒消化完的請求，會先被去重，然後只有最新的請求才會被發送到伺服器端處理。
在伺服器端，Linear 原本是使用 GraphQL API，但後來發現在大量資料的請求，GraphQL 會有效能瓶頸，因為 GraphQL 需要在伺服器端都拼接完資料後，才傳送給客戶端。因此對於要處理比較大資料的接口，Linear 改採 Streaming REST API，用串流的形式，從資料庫送到伺服器再送到客戶端，讓使用者不用等到所有資料好後才能一次看到資訊呈現，使用上的體感增快。
在資料庫的規模化上，Linear 最開始選擇 PostgresQL 的讀取 replica 時，發現在處理比較大筆資料上，PostgresQL 效能並不是太好；在比較多個方案後，最後他們決定用 MongoDB 作為 replica，並設計一個同步的機制，把資料從 PostgresQL 複寫到 MongoDB 上，然後Streaming REST API 是去跟 MongoDB 拿資料。
以上摘要了 Linear 如何設計出一個對使用者來說速度極快的專案管理工具，演講中有非常多設計的細節，推薦大家可以完整看完！
[軟體業職涯] 後 ChatGPT 時代的新職業 — AI 工程師
在開源界小有名氣的工程師 swyx 先前發了一篇《The Rise of the AI Engineer》分析在後 ChatGPT 時代出現的新職種 — AI 工程師 (AI Engineer)。
在 ChatGPT 剛出來時，許多企業開始招募提示詞工程師 (Prompt Engineer)，但是在過去半年的演進，企業開始發現只有提示詞完全不夠，想要把大型語言模型成功整合進產品，還需要其他不同的工具與技能，例如要搭配嵌入 (Embeddings) 與向量資料庫，同時要會用 OpenAI 自己都推的 LangChain。
要懂提示詞，又要懂這些不同的工具與技能，這顯然不僅是提示詞工程師，但這也已經超出傳統對全端工程師的定義，同時在做的事也不是機器學習工程師，或研究科學家在做的事。因為過去的職稱都不全然吻合這個新興類別，swyx 用 AI 工程師 (AI Engineer) 一詞來定義這個新職種。
他的定義分界是劃在 API 這一層。API 層的左端是 AI 研究科學家，他們精進模型並開發 API (例如 OpenAI 開發 ChatGPT API 或 Anthropic 開發 Claude API)。API 層右邊則是有 AI 工程師以及傳統的全端工程師。在 swxy 的文中，很清楚地區分從底層到應用層有哪些不同的角色。根據他的觀察，現在 AI 工程師這類別，在企業中多半會由偏向應用端的工程師負責，因為仍是消費開發好的 API。
先前 ExplainThis 就有分享，蘋果等大廠，在一般軟體工程師的職缺中，已經有加入 LangChain 的技能要求。相信這個趨勢只會越來越增長，就像過去全端工程師要會前端與後端，可預見未來的全端工程師，會需要前端 + 後端 + 整合 AI 的能力。
本期推薦
受到生成式 AI 浪潮衝擊，在過去一年流量砍半的 Stack Overflow 推出了 OverflowAI。奠基在過去累積的龐大資料，相信 Stack Overflow 仍有力挽狂瀾的機會 [連結]
Turporepo 從 Go 遷移到 Rust，先前他們分享為什麼選擇用 Rust 改寫 [連結]，最近則分享具體是怎麼遷移的 [連結]。對於語言選擇與遷移有興趣的人，這兩篇很值得一讀。
Dan Abramov 辭去在 Meta 的工作，感謝他過去的付出。好消息是，雖然不在 Meta 全職工作，Dan 仍會持續在 React 的社群中 [連結]。他提到會在這個時間點辭職，一個原因是目前 React 的團隊相當完整，且持續擴張中。目前也有看到 Meta 持續在招募 React 團隊的相關職缺 [連結]
自從 React 推出後，JSX 逐漸被許多前端框架採用，包含 Preact、Solid、Qwik 等等，都選擇用 JSX 這個看起來像 HTML 但實際上是 JavaScript 的語法。這篇文章帶你了解 JSX 的歷史緣由。
對於工程師來說，寫作是一項很重要的技能，不論是轉寫技術文件、設計文件，除了寫程式外，其實有非常多的場合是需要寫作的。《Why you should write?》總結了為什麼身為工程師的你需要寫作
Replit 上的 AI 專案在過去一年有了爆炸性 34 倍的成長，其中有八成是基於 OpenAI 的開發，使用到 LangChain 這類開源 AI 工具的專案也大幅成長。所有專案中，最多人使用 Python 與 JavaScript 這兩個程式語言 [連結]
過去社群中許多人稱讚 Expo 的官方文件中，程式碼段落的配色很好看。最近 Expo 在 VSCode 上推出免費的主題配色。喜歡的人或想換換編輯器配色的人，可以一試 [連結]
🎉《ChatGPT 指令大全與創新應用》電子書上市
最後，假如你有興趣全面性了解 ChatGPT，並且學習如何實作基於 ChatGPT 的應用程式，千萬不要錯過了 《ChatGPT 指令大全與創新應用》目前電子書也全面上市，之前有私訊詢問電子書的朋友，千萬別錯過了 (博客來購買連結在此) 😊