前端工程師轉全端：沿著分層架構把資料層、商業邏輯層、持久層一層層走完

1. 開場：只會 React 已經不夠 0:00–0:24

作者開宗明義指出，前端工程師只會 React 或 Angular、只會刻 UI 元件的時代結束了，公司期待你能端到端交付、也能碰後端。這支影片要講的是 10 個前端轉全端i必須掌握的概念。

推理因為觀眾多半已經感覺到「會 React 卻在面試被問後端」的落差，作者不花時間說服你這件事，而是直接把它變成前提，並承諾用 10 個概念把落差補上。他刻意用「端到端交付」而不是「學後端」來描述目標，暗示接下來要講的不是一堆技術名詞，而是一條從前端往後延伸的路徑。

AI 補充作者沒有說破的是：「端到端交付」在公司裡通常不是要你去寫核心後端服務，而是要你在一張票（ticket）上不會卡在交界處——需要改一個 API 欄位時你自己能改，需要判斷慢在哪一層時你自己能判斷。這決定了後面所有內容的取捨標準：不是要你變成後端工程師，而是要你在每一層都有足夠的語言可以對話與除錯。這也解釋了為什麼後面的建議幾乎都是「回你自己的 codebase 找某個東西」，而不是「去修一門課」。

2. 分層架構的全貌 0:24–0:52

他先畫出整體地圖：前端做元件與狀態管理，向後端要資料、送出更新，資料最後落到 data layeri。用分層架構（layered architecturei）的觀點看，這是第一個要征服的領域。整支影片就是沿著這張圖從資料層往下走。

推理因為要避免變成流水帳式的名詞清單，作者先用分層架構把整個系統攤開：左邊是前端應用（Angular／Vue／React）與它的狀態管理，往右是 1. Data Layer，再往右是 2. Business Logic Layer，最後是 3. Persistence Layer。前端跟資料層之間的箭頭是雙向的——你送出動作、你收回資料——這條雙向箭頭正是前端唯一已經站著的位置。他因此宣告：第一個要征服的領域就是離你最近的資料層。

• C分層架構：前端→資料層→商業邏輯層→持久層→基礎設施層，只跟相鄰層對話→ 畫地圖

AI 補充畫面上這張圖有一個細節值得注意：資料層的圖示是一束纏在一起的網路線，商業邏輯層是一個大腦，持久層是一疊硬碟。這不是裝飾，而是三個層各自的職責隱喻——傳輸、決策、記憶。後面每次講到一個新概念，作者都會回到這張圖指出它落在哪一格；如果你在看的時候感覺散亂，回頭問「這個東西在哪一層」通常就能定位。 另外要補上作者跳過的一步：分層架構的價值不只是分類，而是「每一層只能跟相鄰層對話」。這條約束正是後面很多設計（例如為什麼要多一層專門服務前端的後端）之所以成立的原因。

3. HTTP：REST 底下的請求與回應 0:52–2:17

要往資料層深入，第一步是真的懂 REST 背後的協定 HTTPi。作者用「一封 email」比喻：客戶端送出一段文字，伺服器拆出 method、path、protocol 和 headers（描述資料的資料），再組出結構幾乎相同的回應，多了 status codei 與 status message，body 可能是 JSON 或 HTML。

推理因為前端對 REST 的熟悉停在「呼叫它、拿到 JSON」，作者用一個降維的比喻把它變回可讀的東西：HTTP 請求就是一張紙、一封 email，是純文字。畫面上他把一行 `GET / HTTP/1.1` 拆成 method、path、protocol version，下面接 `Host:` 與 `Accept-Language:` 兩個 headeri，並標注「headers 是關於資料的資料」。接著他把回應並排放上來——結構幾乎一模一樣，只是第一行換成 `HTTP/1.1 200 OK`（protocol version、status code、status message），下面同樣是 headers。這個對稱是這一段真正的重點：請求與回應不是兩種東西，是同一種格式的兩個方向。

• AHTTP 請求與回應其實是同一種純文字格式的兩個方向→ 批判類比

AI 補充作者說 body「我這裡沒有畫進去」，但沒有補上為什麼可以省略——因為 HTTP 訊息的結構是「起始行 + headers + 空行 + body」，body 是可選的，GET 請求通常根本沒有 body。理解這個結構有一個直接的實用價值：當你在 network tab 看到問題時，你會知道要往哪裡看——狀態不對看 status code，快取或編碼不對看 headers，內容不對才看 body。 畫面上的回應範例還藏了一個下文的伏筆：headers 裡已經出現 `cache-control: public, max-age=3600`。作者這時只說「headers 是關於資料的資料」，暫時沒有展開它的意思。

4. REST 端點設計與怎麼實際上手 2:17–5:18

RESTi 之所以叫 REST，是因為端點依統一標準設計：資源（如 survey）加 ID，配上定義明確的 HTTP 動詞完成 CRUDi。作者說不要背 status code，要動手：回自己的 codebase 看所有資料請求，找後端要 OpenAPIi／Swaggeri 文件，從外往內理解，最後試著自己擴充一個端點。他還講了自己收到 swagger 檔卻不知道那是什麼、因此被當成 junior 的親身經歷。

推理因為 HTTP 本身只規定了訊息格式、沒規定該怎麼組織 API，作者接著補上 REST 加上去的那層約定：用資源當名詞、用 HTTP 動詞當動作。畫面上他把兩欄並排——左欄 GET／POST／DELETE／PUT，右欄 `/surveys`、`/surveys/123`、`/surveys/123/resp...`——兩欄交叉就組合出所有 CRUD 操作，回應是 JSON。這正是「uniform（統一）」的具體含義，也是 REST 的 R 所指的東西。 有了這個結構，他才能回答「我到底要學多少」。答案不是背 status code，而是三個動作：回自己的 codebase 看所有資料請求；去找後端要 OpenAPI／Swagger 文件，那個 UI 會把所有端點攤在你面前；然後試著自己擴充一個端點——如果後端也是 TypeScript／Node 會容易得多，C# 或 Java 就等於再學一門語言。面試的實際考法他也講了：現場把某個資源的端點寫出來（拿 user 當例子，取得、修改、刪除各是什麼請求、各回什麼）。

• CREST：用資源當名詞、HTTP 動詞當動作的一組 API 設計約定，不是協定→ 畫地圖
• R拿到 Swagger/OpenAPI 檔可以直接拿來做什麼→ 存＋回想

AI 補充這一段最有價值的其實是那個親身經歷：他當時收到後端傳來的 swagger 檔，卻不知道那是什麼，被團隊當成 junior。這個故事的重點不在尷尬，而在於它示範了一種特定的知識落差——不是「不會寫」，而是「不認得業界共通的東西」。這種落差在面試裡致命，因為它會被解讀成「沒待過成熟團隊」。 作者說「從外往內」也值得補一步他沒展開的：先看契約（有哪些端點、進出什麼形狀），再看實作（這個端點內部做了什麼）。契約是穩定的、可讀的、跨語言的，實作才需要語言知識。這就是為什麼一個不懂 Java 的前端，仍然可以完全看懂一個 Java 後端的 API。

5. 冪等性、網路分層與 TCP/IP 5:18–7:55

想更深入就要能回答「REST 為什麼更容易擴展」。關鍵是冪等性（idempotencyi）：同一個操作做多次結果不變，像乘以 1。因為前端常有 retry 機制，非冪等端點被重試會造成無法預測的副作用。接著他建議認識 DNSi 與網路七層（我們只工作在第六、七層），以及 IPi 負責定址、TCPi 保證封包依序且不遺失。

推理因為擴展性的問題無法用「會打 API」回答，作者引進第一個抽象概念：冪等性。畫面上他放的是一個矩陣乘以單位矩陣仍等於自己的例子（口頭講的是「乘以 1」）——同一個操作做幾次，結果都一樣。他接著把它接回前端最熟悉的場景：前端常有 retry 機制；如果一個請求其實成功了、只是回應沒收到，重試一個非冪等的操作就會做兩次，資料庫因此出現無法預測的變化。所以除了 POST，端點都應該追求冪等。 往更底層走，他建議認識 DNS 與網路分層。畫面上是完整的 OSI 七層圖，右邊圈出「Software Layer」；他的說法是應用開發者實際工作在最上面幾層——七層的 DNS／HTTP、六層的資料表示——底下那些是我們站著的地基。最後他點到 IP 負責定址（header 記著從哪來、要去哪，路由器靠它轉送）與 TCP 負責可靠性（保證封包依序抵達、不遺失），所以前端不必自己處理分塊回應的重組。

• R冪等與安全是兩個不同維度→ 存＋回想

AI 補充這裡有一個作者跳過的推論步驟值得補上：REST 之所以容易擴展，主因其實是無狀態，不是冪等性。因為伺服器不保存會話狀態，任何一台機器都能處理任何一個請求，你才能無腦加機器。冪等性解決的是另一個問題——重試時的安全性。兩者在面試裡常被一起問，但它們回答的不是同一件事，分清楚會讓你的答案比多數人準確。 冪等性的定義也有一個常見陷阱：DELETE 是冪等的（刪第二次結果仍是「不存在」），但它不是「安全的」（safe，指完全不改變狀態）。GET 兩者皆是，POST 兩者皆非，PUT 冪等但不安全。面試官問「哪些動詞是冪等的」時，真正在確認的是你有沒有分清楚這兩個維度。

術語:OSI modeli

6. 該讀多深：把網路當歷史讀 7:55–9:30

主持人問：這些到底要學到多深？作者的答案是——不是每天用到的東西，讀了也會忘，買本厚書硬啃只會半途而廢（他自己讀 15 頁就放棄了）。對超出日常範圍的主題，把它當讀歷史：你沒親身經歷過那些事件，但要能講出一條連貫的故事，說明 IP／TCP 怎麼堆疊成你每天在用的東西。

推理因為前一段丟出了大量可以無限深入的主題，作者必須先給一個停損點，否則觀眾會被淹沒。他的判準是使用頻率：不是每天用到的東西，讀了也會忘（use it or lose it）。他用自己的失敗當證據——買了一本厚厚的網路書，讀了 15 頁就放棄，因為書很枯燥、而且他當時有更重要的問題要解決。 然後他給出替代的深度標準：把它當讀歷史。你沒有親身經歷過那些事件，但你要能講出一條連貫的故事——IP 做什麼、TCP 補上什麼、它們怎麼疊成你每天在用的東西。這個標準的巧妙之處在於它可驗證：你能不能一口氣講完，自己馬上知道。

AI 補充「把它當歷史讀」這個比喻背後其實是一個更精確的學習原則：對於不會反覆練習的知識，該追求的是可提取的結構，而不是可執行的細節。你需要的是一張能掛東西的骨架——遇到新資訊時知道它該掛在哪裡，而不是一堆孤立的事實。 這也回頭解釋了前面那些「回你的 codebase 找」的建議為什麼一直重複：那不是懶人做法，而是把知識綁在你會反覆遇到的東西上。綁得住的部分用練的，綁不住的部分用故事記——這就是作者實際在用的分配策略，只是他沒有明講。

7. HTTP 快取：Cache-Control 與 ETag 9:30–11:46

多數人把瀏覽器快取視為理所當然，卻很少有人能打開 console 說出快取現在的狀態。瀏覽器看 response 的 cache-controli 決定要不要重用，max-agei 說明能留多久，過期後用 ETagi 跟伺服器確認有沒有新版本。作者要你明天回公司就打開 network tab，挑一個靜態資源把這三個 header 找出來。

推理因為快取是瀏覽器自動做的，多數人從沒檢查過它的狀態。作者先講機制：瀏覽器讀回應的 `cache-control` 決定要不要重用；如果可重用，會標明是 private 還是 public 快取，並附上 `max-age` 說明能留多久；超過時效就用 `ETag` 去問伺服器有沒有新版本。畫面上他放了一張完整的決策樹——可重用嗎？要每次重新驗證嗎？中介快取能存嗎？最長能留多久？——每個分岔對應一個 cache-control 的值（no-store、no-cache、private、public）。 然後他做了這一段真正的動作：打開自己的 DevTools，指著一個 JavaScript 檔的 Response Headers，把 `Cache-Control: public, max-age=86400` 圈起來，旁邊還有 `Age: 10843`。max-age 是允許保存的時間，Age 是這份回應已經被存了多久，兩者一比就知道還剩多少。他要你明天回公司就做同一件事。

• E作者自己截圖：Cache-Control: public, max-age=86400 配 Age: 10843→ 存＋演練
• CHTTP 快取：靠 Cache-Control 判斷新鮮度，過期後靠 ETag 重新驗證→ 畫地圖
• Rno-cache 不是不快取→ 存＋回想
• P去看自己專案的快取設定→ 練習

AI 補充這一段是全片方法論最完整的示範：先給機制（決策樹）、再給實例（自己的 network tab）、最後給一個明天就能做的動作。三者缺一，知識就綁不住。 要補上作者略過的一個關鍵區分：`max-age` 過期不代表「快取失效」，只代表「需要重新驗證」。這時瀏覽器帶著 `If-None-Match: <ETag>` 去問，伺服器如果內容沒變就回 `304 Not Modified`——一個沒有 body 的空回應，瀏覽器繼續用本地那份。所以 ETag 省下的是傳輸量，不是往返次數。真正要連往返都省掉，靠的是還沒過期的 max-age。這個差別直接決定了你該怎麼配置靜態資源：檔名帶 hash 的資源可以給極長的 max-age（內容變了檔名就變），HTML 入口檔則必須每次驗證。

術語:HTTP cachingi

8. GraphQL 為何出現：under-fetching 11:46–13:13

GraphQLi 是較新的取資料方式，動機是 REST 的限制，其中之一是 under-fetchingi：通用資源端點給的資料不夠，抓一份清單後還要為每一筆再打一次請求，一個畫面可能要打上幾十次。GraphQL 的回應是給前端一個近似資料庫的查詢層，讓幾十個請求變成一次 query、一次 response。

推理因為 REST 的統一介面是它的優點也是它的天花板：端點的形狀由後端事先決定，而通用的資源端點永遠不會剛好等於某個畫面需要的資料。畫面上他把兩種做法並排：左邊 REST 要打三次——`/users/<id>` 拿到使用者、`/users/<id>/posts` 拿到貼文、`/users/<id>/followers` 拿到追蹤者；右邊 GraphQL 只送一個 query，裡面同時要 name、posts 的 title、followers 的 name，回來一份剛好的 JSON。 這個對照讓 GraphQL 的動機變得不必解釋：它不是「更好的 REST」，而是把「決定資料形狀」這件事的決定權從後端移到客戶端。作者用一句話總結——GraphQL 給前端一個近似資料庫的查詢層。

• CGraphQL：把資料形狀的決定權從後端移到客戶端，單一 query 拿齊所需欄位→ 畫地圖
• Runder-fetching 最痛的形式是瀑布式請求→ 存＋回想

AI 補充作者說 under-fetching 會「為每一筆再打一次請求」，這個現象在前端有個更常見的名字：瀑布式請求（request waterfall）。它的代價不只是請求數量，而是延遲會累加——第二次請求必須等第一次回來才知道要打哪些 ID，所以總延遲是往返時間的倍數，不是總和被平行化掉。這也是為什麼「合併成一次 query」的收益比單看請求數更大。 另外要補一個他沒說的權衡：把決定權交給客戶端，代價是後端失去了對查詢成本的控制。REST 的每個端點成本是可預估的，GraphQL 的一個 query 可能便宜也可能極貴，取決於客戶端怎麼寫。這個代價後面會以一個具體的故障形式出現。

9. BFF：後端為前端 13:13–15:24

當同一個資料層要服務網頁、手機、桌面等不同客戶端，各自需要的資料視圖都不同，硬拼在 REST 上會變成科學怪人。乾淨的做法是 BFFi（Backend For Frontend）：由前端／全端工程師建的後端，把背後多個服務的回應縫成單一回應給自己的客戶端。作者說這通常是前端能貢獻的第一塊架構。用 GraphQL 做 BFF 的好處是彈性夠大，多半一個就夠；用 REST 做則每個客戶端都得各來一個。

推理因為同一份資料要服務網頁、手機、桌面等不同客戶端，而每個客戶端要的視圖都不同，硬把所有需求塞進同一套 REST 端點，作者的形容是會長成一個「科學怪人」。乾淨的做法是加一層：BFF——由前端或全端工程師建的後端，專門服務自己的客戶端。畫面上這個結構很清楚：左邊是 API 消費者，中間綠圈圈住的是 BFF 回傳的那份完整 JSON，右邊綠圈圈住的是它背後真正被呼叫的一堆服務——DynamoDB 存使用者資料、API Gateway 接訂單服務、Lambda 管庫存、Aurora 管定價。BFF 的工作就是把這些回應縫成一份剛好合用的回應。 他強調這通常是前端能貢獻的第一塊架構：後端工程師建那些服務，前端建這一層。而用 GraphQL 做 BFF 有個額外好處——因為客戶端本來就能自選欄位，多半一層就夠；如果用 REST 做 BFF，每個客戶端都得各來一層，否則又會變回科學怪人。

• CBFF：專門服務某類客戶端的薄後端，把多個下游服務縫成剛好的一份回應→ 畫地圖

AI 補充作者沒有明說但值得指出的是：BFF 的價值不只在資料形狀，更在「歸屬權」。這一層屬於前端團隊，意味著前端要改欄位時不必排進後端團隊的迭代——組織上的解耦往往比技術上的收益更大。這也是為什麼 BFF 最早是 SoundCloud 為了讓行動端團隊不被後端阻塞而提出來的。 代價同樣要說清楚：多一層就多一個要部署、要監控、要處理故障的東西，而且它非常容易長成第二個單體。判準是——如果你只有一種客戶端、而且後端 API 本來就貼合你的需求，BFF 是純粹的成本。

10. 圖的彈性與 N+1 問題 15:24–18:24

GraphQL 叫 graph，是因為資料是彼此相連的節點：查到蒙娜麗莎就能順著走到達文西，而 REST 的資源彼此獨立，只能整包拿（over-fetchingi）或不夠拿（under-fetching）。彈性的代價是 N+1 問題：查 100 個產品、再為每個產品各查一次價格，等於對自己的資料庫發動 DDoS。解法是把查詢合併成一次 SQL，GraphQL 生態的工具叫 DataLoaderi。

推理因為要先理解自由有多大，才理解代價有多重，作者先解釋 GraphQL 為什麼叫 graph：畫面上是一張知識圖譜，蒙娜麗莎連到達文西（painted）、連到羅浮宮（is in）、羅浮宮連到巴黎（is located in），節點彼此相連。REST 的資源是各自獨立的島，圖的節點則可以一路走下去。他在同一張圖上圈了兩塊不同的子圖，旁邊寫著兩行字：gives the client optionality、gives the client a schema——你要拿多少，自己圈。 然後代價出現了。如果你查一份產品清單、又要每個產品的價格，而 resolver 是逐筆解析的，那就是 1 次清單查詢加上 N 次欄位查詢——這就是 N+1。作者把後果講得很直白：這等於對自己的資料庫發動 DDoS。主持人補上關鍵的一句——這些查詢是同時發出的獨立查詢，如果有五萬個使用者各自這樣打一次，資料庫會被自己人打垮。解法是在送出前把它們合併成一次 SQL，GraphQL 生態的標準工具叫 DataLoader。

• AN+1 查詢就像對自己的資料庫發動 DDoS→ 批判類比
• RDataLoader 是批次不是跨請求快取→ 存＋回想

AI 補充N+1 值得補上一個判斷方法，因為它幾乎不會在開發環境出現：本機的測試資料通常只有幾十筆，N=20 的時候一切正常，上線後 N=5000 才炸開。所以偵測它不能靠體感，要靠監測「單次請求觸發的 DB 查詢數」——這個指標一旦隨資料量成長，就是 N+1。 DataLoader 的原理也值得說明，因為它常被誤以為是快取：它其實是把同一個事件迴圈週期內收到的所有取值請求先攢起來（batching），到週期結尾一次送出合併查詢，再把結果分派回各個 resolver。所以它不改變你的 resolver 寫法，只改變它們實際打出去的時機——這是它能無痛套用的原因。 順帶一提，N+1 完全不是 GraphQL 獨有的。任何 ORM 在迴圈裡讀取關聯欄位都會產生一模一樣的問題，只是 GraphQL 因為讓客戶端自由組合欄位，讓它更容易被意外觸發。

術語:N+1 problemi

11. 資料串流：WebSocket 與 SSE 18:24–21:24

REST 與 GraphQL 覆蓋約 95% 的日常工作，剩下的是需要即時更新的場景。WebSocketi 開一條雙向通道，聊天類應用（WhatsApp、Messenger、Instagram）都靠它，但難實作也難擴展。若通訊是不對稱的——像 ChatGPT，你送一句、伺服器回一大串 chunk——用 Server-Sent Eventsi 就好：瀏覽器原生、兩行程式碼、更好擴展。

推理因為請求／回應模型本質上只能由客戶端發起，即時場景（會跳動的圖表、聊天訊息）只能靠每五秒問一次來模擬，而那對伺服器壓力極大。所以有了 WebSocket：開一條雙向通道，伺服器能主動推、客戶端也能送。作者說 WhatsApp、Facebook、Instagram 都是這樣運作的。 但他接著做了這一段最有價值的判斷。現在的 AI 應用（像 ChatGPT）也在串流，可是那個通訊是不對稱的——你送一句話，伺服器回一大串 chunk。畫面上他打開 OpenAI 的回應，一行行 `event: delta` 與 `data` 疊著往下，旁邊是幾行 `e.data` 的接收程式碼。既然你幾乎不往上送，就不需要雙向通道：Server-Sent Events 是瀏覽器原生的、兩行程式碼就能收、而且更好擴展。他給的判準很乾脆——只要客戶端送的訊息遠少於伺服器送的，就用 SSE，不必上 WebSocket。

• RSSE 跟 WebSocket 的選用判準→ 存＋回想

AI 補充SSE 更好擴展的原因作者沒展開，值得補：SSE 就是一個一直不關閉的 HTTP 回應，所以它天然享有 HTTP 的一切基礎設施——反向代理、負載平衡、CDN、驗證機制全部照用，斷線後瀏覽器還會自動重連並帶上 `Last-Event-ID` 續傳。WebSocket 則要先用 HTTP 握手再升級成另一種協定，中間每一層代理都得特別支援它，這才是「難擴展」的實際含義。 SSE 的限制也要說清楚，否則會用錯地方：它只能傳文字（要傳二進位得先編碼），而且在 HTTP/1.1 下受同網域連線數上限影響（每個網域約六條），開太多分頁會卡住——HTTP/2 之後這個限制才消失。需要低延遲雙向（多人協作、遊戲、語音）時，WebSocket 仍然是唯一選項。

12. 商業邏輯層：後端的大腦 21:24–23:38

沿著分層往下走，離開資料層就是 business logic layeri——應用真正的大腦，決策在這裡發生。請求進來後被 REST API 攔下，觸發附掛的函式：處理、驗證，套用像 if 一樣的商業規則，最後才呼叫資料庫（persistence layeri）。這些程式碼通常被歸類成 controlleri。這一層最常被問的是驗證與授權，例如 JWTi 的完整生命週期：你怎麼拿到它、後端拿它做什麼。

推理因為前面三種模式講的都是資料怎麼流動，作者現在要處理資料到達之後發生什麼。畫面上他把鏡頭拉遠，回到最初那張分層圖——現在圖上已經掛滿了這一路講過的東西：資料串流、REST、GraphQL、Underfetching、BFF 各自被畫在下方，而中央那三格 1. Data Layer、2. Bussiness Logic Layer、3. Persistance Layer 依然是主幹。這個「拉遠再對位」的動作本身就是他的教學方法。 商業邏輯層是應用的大腦：請求被 REST API 攔下後，觸發附掛的函式，處理、驗證、套用像 if 一樣的商業規則，最後才呼叫資料庫。相對地資料庫是記憶——這個大腦／記憶的對比是他給這兩層的定位。實作上這些程式碼通常被歸類成 controller。他坦承這一層可以自成一支影片，只挑了面試最常考的切入點：JWT 的完整生命週期——你怎麼拿到它、後端拿它做什麼。

• C商業邏輯層（大腦）：接住請求後驗證、套用商業規則，再呼叫資料庫→ 畫地圖
• RJWT 的三個必知陷阱→ 存＋回想

AI 補充作者把 controller 說成「大腦」稍微含糊了一個重要區分，值得補上：在分層清楚的後端裡，controller 其實應該很薄——它負責接請求、驗參數、呼叫服務、組回應，真正的商業規則放在 service 或 domain 層。之所以要分，是因為商業規則必須能脫離 HTTP 被測試與重用（同一條規則可能同時被 API、排程任務、後台工具呼叫）。面試裡問到「你怎麼組織後端程式碼」時，能講出這個分工就足以區隔出經驗深度。 JWT 的生命週期作者只留了問題沒給答案，補完整：登入成功後伺服器簽發一個由 header、payload、signature 三段 base64 組成的 token，前端後續在 `Authorization: Bearer <token>` 帶著它；伺服器不查資料庫，只用密鑰驗簽章就知道它沒被竄改。關鍵在於 payload 是編碼不是加密——任何人都能解開讀內容，所以絕不能放敏感資料；而且因為伺服器不存狀態，token 一旦簽發就無法單獨撤銷，這正是要搭配短效期 access token 加上 refresh token 的原因。這也是面試官問「JWT 怎麼登出」時真正想聽的東西。

13. 清洗驗證與 DTO 23:38–25:24

使用者通過驗證i之後，下一步是 sanitize 與 validate：確認送來的 email 真的是 email、username 裡沒有被注入 JavaScript。接著才進到持久化，多數後端框架會用 DTOi（Data Transfer Object）把資料打包成統一形狀，一路在後端管線裡傳遞直到寫進資料庫。作者形容 DTO 是「資料送進資料庫前的包裝」。

推理因為身分驗證只證明「你是誰」，不保證「你送的東西是乾淨的」，所以緊接著要做 sanitize 與 validate：確認送來的 email 真的是 email 的形狀、username 裡沒有被塞進 JavaScript，以及各種攻擊者會做的骯髒手法。畫面上「Validation」與「DTO」兩個標題並列，下面是一張 UML：Data Transfer Object 在最左，往右是 Remote Facade（accepts from and sends to remote clients），再往右是 Business Logic，而 Remote Facade 底下有一條 translates to/from DTOs 的虛線指向 Business Object。 這張圖正好說明 DTO 的位置：它是邊界上的形狀，不是內部的模型。作者的比喻是「資料送進資料庫前的包裝」——前端送來 username、name、email，這些原始欄位要先被打包成一個統一形狀，才在後端的管線裡一路傳遞下去。主持人用一個具體流程覆述確認：使用者送出表單 → 經過 REST API → 到後端 → 用 DTO 處理 → 再持久化。

• RDTO 怎麼擋下 mass assignment→ 存＋回想

AI 補充作者說 DTO「很抽象、沒碰過後端 codebase 會難懂」是誠實的，但有一個更精確的說法可以讓它立刻具體：DTO 存在的理由是讓「外部契約」與「內部模型」可以各自演化。如果 controller 直接把前端送來的物件交給資料庫模型，那你的資料表結構就等於公開 API——改欄位名會直接打壞客戶端，而多送一個欄位就可能被寫進資料庫（這就是有名的 mass assignment 漏洞）。DTO 是那道明確的閘門：只有被宣告的欄位能通過。 順序也值得釐清，因為作者講得比較鬆：正確的次序是先 validate（形狀對不對、必填有沒有、型別對不對）再 sanitize（把危險內容處理掉），而且真正防 XSS 的關鍵不在寫入時清洗，而在輸出時依情境轉義——同一段文字放進 HTML、放進屬性、放進 JavaScript 需要的轉義方式並不相同。寫入時清洗是輔助，不是防線。

術語:sanitizationi

14. 持久層：NoSQL 與 SQL 怎麼選 25:24–30:12

最後一層是資料庫。作者要你先把它想成「一個可以下聰明查詢的檔案」——底下仍然是硬碟，只是雲把它抽象掉了。分兩大類：NoSQLi 存非結構化資料，沒有約束也沒有保證（新增「最愛顏色」欄位後，舊資料不會有），像把東西全丟進一個房間；SQLi 是有 schemai 的關聯式資料庫，形狀不符就報錯，99% 的商業軟體用它。實務上兩者混用：log 這種沒有關聯的資料用 NoSQL，電商的商品／價格／目錄這種關聯很重的用 SQL。

推理因為資料庫容易被當成黑盒子，作者先做一次除魅：不管雲怎麼抽象，它終究是一台有硬碟的電腦；最簡單的想法是「一個可以下聰明查詢的檔案」——如果只是文字檔，你得一行行找，資料庫多的是那層讓你能快速取回的抽象。畫面上持久層往右分出兩個分支：3.1 Unstructured Data - NoSQL 配一疊亂堆的紙，以及 Organized Storage - SQL 配一整櫃分格收納的樂高。這組對比是整段的論證。 NoSQL 存非結構化資料：丟進去什麼形狀都行，之後用 ID 撈回來，但沒有任何關於形狀的保證。他舉的例子很實際——產品經理說每個使用者要多一個「最愛顏色」，你加了，但此前建立的所有使用者都沒有；你查出來的資料有些有、有些沒有，於是寫不出能規模化的穩固邏輯。沒有約束的另一面就是沒有保證。SQL 則相反：畫面上那個分格收納櫃，紅色的積木塞不進藍色的格子就是報錯。這就是 schema——欄位、型別、結構的宣告；他接著把 MediaWiki 的實際資料表結構攤開，user、user_properties、user_groups、ipblocks 一格格連著，每個欄位都標明型別。99% 的商業軟體用這種，因為商業邏輯需要可預測的輸出。 最後他給選型判準：多數架構兩者混用。關聯少、量大、彼此獨立的資料（例如登入紀錄這類 log）用非結構化；關聯密而且關聯本身有意義的（電商的商品、價格、目錄）用關聯式。

• Cschema：SQL 在寫入時強制守住資料形狀，NoSQL 把這責任丟給讀取端→ 畫地圖
• EMediaWiki 真實資料表：user、user_properties、user_groups、ipblocks→ 存＋演練

AI 補充有一個作者略過的重點會改變你的判斷：NoSQL 並不是「沒有 schema」，而是「schema 由讀取端負責」。資料的形狀假設沒有消失，只是從資料庫移到了你的程式碼裡——那個「有些使用者沒有最愛顏色」的問題，正是這個轉移的帳單。所以真正的選擇不是「要不要 schema」，而是「schema 由誰來守、什麼時候發現違規」：關聯式資料庫在寫入時就擋下，文件資料庫則等到讀取時才炸。 另外「NoSQL 比較快」這個常見說法需要限縮條件：它快在單一文件的讀寫與水平擴展，因為資料是聚合在一起的、不需要跨表 JOIN。但一旦你的查詢需要關聯多份文件，你就得在應用層自己做 JOIN，那通常比資料庫做慢得多。所以判準其實是「你的存取模式是否已經確定」——確定且固定，文件資料庫可以貼著它設計；還會變，關聯式的彈性查詢會救你一命。

15. CAP 定理與讀寫分離 30:12–33:05

系統設計面試一定會問資料庫擴展，而背後的心智模型是 CAP：一致性、可用性、分區容錯三者不可兼得，只能挑兩個。關聯式資料庫的資料多半在單一伺服器上，流量成長時先垂直加硬體，但很快撞到物理上限。第一個橫向解法是唯讀複本（read replicai）：主庫負責寫，複本供讀。對照 CAP，這換來了分區與可用性，代價是一致性——資料同步有延遲，讀到主庫和讀到複本可能拿到不同版本。

推理因為擴展手段很多、單獨背會變成散落的記憶點，作者先立一個統一框架。畫面上是四行字：Database Scalability、CAP Theoremi，底下條列 Consistency、Availability、Partitioning——三者不可兼得，只能挑兩個。他承認這很抽象，所以立刻拿實際情境去套。 先看沒擴展前的樣子：關聯式資料庫的資料多半住在同一台伺服器上，因為查詢要跨好幾張表、好幾筆記錄組合起來。流量上來時第一反應是加硬體——加 CPU、加記憶體、加硬碟——但這條路會撞到電腦的物理上限。 第一個真正的手段是唯讀複本。畫面上一個 master 在上、三個 read-only replica 在下，虛線從 master 流向它們。後端往 master 寫，其他服務從複本讀，壓力就不集中在單一實例。然後他做了這一段最重要的動作：把它放回 CAP 上檢查——資料被分散到不同節點所以有了分區，master 掛掉還能讀複本所以有可用性，但寫入到複本之間有延遲，同一時刻讀 master 和讀複本可能拿到不同版本，一致性因此被犧牲了。他也提醒這個模式雲端資料庫多半內建，你不用自己實作，但要能解釋。

• CCAP：分區容錯是網路系統的前提而非選項，真正的取捨在分區發生那一刻選 CP 或 AP→ 畫地圖
• Rread replica 完全不解決寫入壓力→ 存＋回想

AI 補充CAP 有一個非常常見的誤讀值得糾正，因為它會影響你在面試裡的答案：CAP 不是「三選二」的自由選擇。分區容錯（P）在任何跨網路的分散式系統裡都不是選項而是事實——網路一定會斷。所以真正的選擇只在網路已經分區的那一刻發生：這時你要繼續回應但可能給出舊資料（選 AP），還是拒絕回應直到恢復一致（選 CP）。網路正常時，一致性與可用性可以同時擁有。作者說的「只能挑兩個」是流傳最廣的簡化版本，能講出上面這層區分會明顯拉開距離。 另外「加硬體很貴」這個說法在今天需要修正：現代單機能垂直擴展i到極高的規格，而且垂直擴展沒有任何架構複雜度。實務上的正確順序幾乎總是——先垂直擴展、先加快取、先修慢查詢，撐不住了才開始動架構。太早分散式化是常見的過早優化。 讀寫分離還有一個作者沒提但會實際咬人的坑：使用者剛送出表單、頁面立刻重新讀取，如果讀請求被導到還沒同步的複本，使用者會看到自己的修改「不見了」。標準解法是「寫後讀自己」——寫入後的一小段時間內，該使用者的讀取強制走 master。

術語:eventual consistencyi

16. 索引與分片 33:05–35:26

第二個加速讀取的方式是索引：讓資料庫在底層建 B-treei，把 full table scani 的 O(n) 換成二分搜尋的 O(log n)——一百萬筆從一百萬次讀取降到約 20 次。第三個是水平擴展i／分片（shardingi）：依 shard keyi（例如 ID 區間）把資料寫到不同的獨立實例。分片放在最後講，因為它對應用程式碼最複雜；對照 CAP，這裡拿到分區容錯，但在一致性或可用性上要讓步。

推理因為表大到一定程度後，光是找到一筆記錄就很慢，第一個手段是索引：讓資料庫在底層建一棵 B-tree（他說是類似二元樹的 B 樹），用二分搜尋取代全表掃描。畫面上這張圖把原理攤得很清楚——上半是 Records，每筆記錄配一個位址 0x2000、0x2100、0x2200…；下半是 Index file，一棵以 LastName 為鍵的樹，Dover 在根、往下 Dover 與 Teapot、再往下 Babbage、Knight、Allen、Gates、Lovelace，每個節點旁邊掛著對應的位址。索引本身就是一份額外的檔案。他接回演算法：全表掃描是 O(n)，一百萬筆就要讀一百萬次；換成樹就是 O(log n)，一百萬筆大約十九、二十次。 第二個手段是水平擴展到資料庫上——分片。畫面上是 Shard Key 欄位經過 HASH FUNCTION 算出雜湊值，再據此分派到 Shard 1 或 Shard 2；作者口頭舉的例子是用 ID 區間：1 到 100 放第一片、100 到 200 放第二片。他把分片排在最後講的理由很明確——它對應用程式碼的複雜度最高。回到 CAP 上檢查：分片明確拿到了分區，但代價落在一致性或可用性，因為你得先確定目標記錄在哪一片才找得到。

• C分片：依 shard key 把大表切到多個資料庫實例，唯一能同時擴展讀寫的手段→ 畫地圖
• R索引用寫入速度換讀取速度→ 存＋回想

AI 補充索引有一個被作者略過、但決定它成敗的事實：索引不是免費的加速器，它是用寫入速度換讀取速度。每一次 INSERT、UPDATE、DELETE 都必須同步維護每一個相關索引，所以索引開太多會讓寫入變慢、佔用額外空間。實務上的正確做法是依實際的查詢模式建索引，而不是「重要欄位都加一個」。 還有一個前端最常誤會的點值得補：索引只有在查詢條件能「照著索引的順序從左邊開始用」時才生效。對欄位做運算（`WHERE YEAR(created_at) = 2025`）、用前綴萬用字元（`LIKE '%abc'`）、或複合索引跳過前面的欄位，都會讓索引失效而退回全表掃描。看執行計畫（`EXPLAIN`）是唯一可靠的確認方式。 分片的兩種切法值得分清楚，因為畫面與口白剛好各講了一種：範圍分片（照 ID 區間切，像作者說的）實作直觀、範圍查詢有效率，但容易出現熱點——新資料全都湧向最後一片；雜湊分片（畫面上那個 HASH FUNCTION）分佈均勻，代價是範圍查詢必須問過所有分片。選 shard key 是分片裡最難也最不可逆的決定：一旦選錯，重新分片是極痛苦的工程。

術語:database indexi

17. 基礎設施層與先找出自己的缺口 35:26–37:30

架構圖上還剩最後一塊：infrastructure layeri——雲、CI/CDi、虛擬機、Docker、serverless、Kubernetes、IaC，這些留待另一支影片。但作者強調，今天要拿資深前端職位，至少要會自己部署前端應用，而資深級面試會同時問架構與 CI/CD。面對這麼多主題不被淹沒的方法是：先搞清楚自己的缺口在哪，而不是從頭學所有東西。

推理因為前面三層都是「程式怎麼寫」，還缺一層「程式怎麼真的跑在世界上」。畫面上這一格擺著 EC2、Docker、Lambda、Kubernetes 四個圖示，底下是靜態資源的部署架構（Route 53 → CloudFront → S3 或負載平衡後的伺服器），旁邊寫著 To be continued...——他明白地把虛擬機、容器、serverless、K8s、基礎設施即程式碼留給下一支影片。 但他不讓這一層整個空著，而是切出對前端最低限度的要求：今天要拿資深前端職位，至少要會自己部署前端應用。他點出一個實際的落差——很多開發者接觸不到部署，可是資深級面試會同時考架構與 CI/CD，即使你現在只寫前端。 然後他做了整支影片的方法論收束：面對這麼多主題，不被淹沒的方法不是從頭學所有東西，而是先搞清楚自己的缺口在哪。這句話呼應了他先前對「該讀多深」的答案——兩次都是同一個原則：先定位，再投入。

• P檢查自己專案的部署六件事→ 練習

AI 補充「至少要會部署前端」這個要求可以講得更具體，因為它其實是一組可檢核的能力：你的專案 build 出什麼、那些檔案被放到哪裡、誰在服務它們、快取怎麼設、環境變數在建置時還是執行時注入、以及出事怎麼回滾。這六個問題如果你都答得出來，你就跨過了那道門檻——而它們全部可以在一個週末用任何一個靜態託管平台親手驗證一遍。 值得補上的是，這一層跟前面講過的東西比想像中更相連：CDN 的行為完全由快取標頭決定，回滾能不能安全依賴的是部署產物是否不可變（帶 hash 的檔名），而部署架構圖上那條 Route 53 就是網域解析。基礎設施不是一個新世界，而是把已經學過的協定知識放到真實環境裡。

18. 從能力圈開始往外擴 37:30–39:18

主持人問：一個資深 React／Angular 工程師，今年想轉全端，第一步該怎麼走？作者的答案是待在自己的能力圈（circle of competencei）裡，再慢慢把邊界往外推——不要一次跳進陌生領域。最後是頻道的 mentorship 導引。

推理因為抽象的建議沒有用，主持人把問題落地成一個具體的人：一個資深 React 或 Angular 工程師，碰過大概一成的後端、大概摸過 REST API 那一層，今年想轉全端。最有效率的起手式是什麼？ 作者的回答只有一句話但份量很重：待在你的能力圈裡，慢慢把那個範圍往外推。這句話同時否定了兩種常見做法——不是去學一門全新的後端語言，也不是從頭補完電腦科學。它把整支影片的所有建議統一了起來：回你自己的 codebase 看資料請求、跟你的後端要 Swagger 檔、打開你正在用的應用的 network tab、看看你們現在怎麼處理某個問題。每一條都是從你已經站著的地方往外踏一步，而不是跳到一塊陌生的土地上。 最後他把話題轉向頻道的 mentorship 與技術評量，收尾。

• C能力圈：你真正理解、能判斷對錯的範圍；策略是待在圈裡慢慢往外推→ 畫地圖

AI 補充「能力圈」這個詞來自投資領域，原意是你真正理解的範圍——重點不在圈子多大，而在你清楚知道邊界在哪。用在學習上，它的意思是：往外推一步的地方，你有足夠的既有知識可以判斷自己做得對不對；再遠一點，你連錯了都不知道。 這也解釋了為什麼作者全片都在推薦「回你的 codebase」而不是「去修一門課」——課程給你的是離你的邊界很遠的知識，你缺乏可以驗證它的參照系；而你自己的專案是你唯一能立刻檢驗對錯的地方。 把整支影片壓成一條可執行的路徑，大致是：先把 REST 與 HTTP 弄到能自己查、能自己除錯（這是最大的一次躍進），再往下摸到你們的商業邏輯與資料庫（先能讀懂，再能改一個端點），同時把部署學會，而 GraphQL、串流、分片這些看你的公司實際用不用——用得到就是每天在練，用不到就當歷史讀，能講出連貫的故事即可。