花園

12 則筆記正在生長。清除篩選 ✕

• 程式碼走讀：一個 jobs handler 的解剖 jobs-outbox|jobs queue 的觀念篇講了鐵律，這篇拿 newsletter-double-optin|newsletter 確認信的 handler 當標本，看鐵律在程式碼裡長什麼樣。 註冊與進入點 ts newsletter-mail.handler.ts（節錄） onApplicationBoot…⇄ 2#程式碼走讀 #nestjs #平台 最後照顧 07-14
• 程式碼走讀：一個 decorator 從標記到落庫的旅程 後台每個寫入端點掛著 @Audit(...) 就會自動留audit-collapse-window|稽核紀錄。decorator 看起來像魔法，拆開只有三站：標記 → 讀取 → 執行。 第一站：decorator 只是貼標籤 ts audit.decorator.ts export const AUDITMETADAT…⇄ 2#程式碼走讀 #nestjs #平台 最後照顧 07-14
• Guard 的疊層順序：限流要站在認證前面 平台有兩個全域 guard：限流（throttler）與 JWT 認證。它們的註冊順序是一個安靜但重要的安全決策：限流在前。 順序反過來會怎樣？帶著偽造或過期 token 的請求先被認證擋下、根本走不到限流——攻擊者可以用無效 token 無限次敲你的認證邏輯（含一次 JWT 驗簽的 CPU），暴力嘗試零成本。限流站前…⇄ 1#nestjs #平台 #安全 最後照顧 07-14
• 全域回應信封與它吃掉的檔案下載 平台所有 API 的成功回應長一個樣：{ data: ... }。這靠一個全域 interceptor 把 controller 的回傳值統一包起來——前端拆信封的邏輯寫一次就好，錯誤格式（{ message, errors? }）也對稱收斂。 信封刻意極簡：不塞 success: true（HTTP 狀態碼已經說了）…⇄ 1#踩雷 #nestjs #平台 最後照顧 07-14
• 欄位級加密：只給會動真錢的祕密 資料庫裡有一類欄位外洩即災難：交易所的 API secret、後台填的 SMTP 密碼。整庫加密太重、也解決不了「DB dump 流出」的場景——我要的是欄位級對稱加密，而且只給真正高敏感的欄位用。 設計上的幾個定案 - AES-256-GCM——authenticated encryption，密文被竄改會在解密時直…⇄ 2#nestjs #平台 #安全 最後照顧 07-14
• 三個環境變數的哲學：memory 預設、redis 可換 平台的快取與分散式鎖各自抽象成 port，背後兩套實作：in-memory 與 redis，用環境變數切換。這個設計的核心信念是：fresh clone 必須零外部依賴就能跑起來。 預設 memory 的理由 新人（或三個月後的自己）clone 下來，npm install 完就該能啟動——不需要先架 redis、不需…⇄ 2#nestjs #平台 #架構 最後照顧 07-14
• Cron 的可觀測性：排程不該是黑箱 排程任務最陰險的故障模式是安靜地不跑。cron 表達式打錯、程序重啟後沒掛回去、上一輪卡死——沒有人會收到通知，直到某天發現三週的清理任務一次都沒執行。所以平台把「排程」與「可觀測」設計成一體。 慣例：@Cron 只准當扳機 @Cron 裝飾器一律放在 presentation 層的 scheduler 檔案裡，而且薄…⇄ 2#nestjs #平台 最後照顧 07-14
• 信件系統的四塊積木：模板、設定、規則與一個不重試的 send 「寄信」聽起來是一個功能，拆開來其實是四個關注點，我把它們做成四塊獨立的積木： 四塊積木 - 版型（layout）——信的外殼。後台上傳 HTML，插槽只有主旨、內容、站名三個變數，上傳當下驗證。多封信共用同一個殼，改一次全站換裝。 - 信件定義（entry）——每封信的內容。feature 在程式碼裡註冊 key、變…⇄ 4#nestjs #平台 #架構 最後照顧 07-14
• 自動儲存 vs 稽核紀錄：折疊窗口的取捨 後台的每個寫入端點都掛稽核——誰、什麼時候、對誰、做了什麼成功的操作，一列一筆。這套機制撞上筆記編輯器的自動儲存時，出了一個好問題：打字停頓 1.5 秒就存一次，寫一小時的文章＝幾百筆「編輯筆記」稽核，其他真正重要的動作（發佈、刪除）全被洗掉了。 選項與抉擇 不記編輯？那「已發佈的文章事後被改過」這種真正有稽核價值的事…⇄ 4#nestjs #平台 #架構 最後照顧 07-14
• 一個事件、三個出口：通知系統的解耦練習 平台有三個長得很像的模組：站內通知（DB + 讀取 API）、SSE 即時推播、outbound webhook（對外部訂閱者投遞）。最初的直覺是把它們做成一個「通知服務」，provider 呼叫時指定要走哪些管道——這個直覺是錯的。 正確的形狀：producer 只派發領域事件，三個出口各自是 listener。 N…⇄ 4#架構 #nestjs #平台 最後照顧 07-14
• Jobs queue 兼職 transactional outbox：一張表兩個身分 每個後端遲早要回答同一題：「這個動作要呼叫外部服務，失敗了怎麼辦？」寄信、打 webhook、通知廠商——這些不能跟 HTTP request 同生共死的事，需要「enqueue + 重試 + 死信 + 可觀測」。我把它做成平台的通用積木：一張 backgroundjobs 表、一個每五秒 tick 的 worker、…⇄ 8#nestjs #架構 #平台 最後照顧 07-14
• 前端殼的三道客製縫：整頁、碎片、配色 後端有 forge-monorepo|platform 套件，前端對應的是 web-kit——登入、版型、選單、主題這些每個後台都要的殼。難題跟後端不同：前端的客製需求是視覺的、瑣碎的、無孔不入的。如果每個 app 想改個顏色都要 fork 整個殼，套件就死了。 我的答案是把客製收斂成三道明確的縫，由粗到細： 1. 整…⇄ 2#前端 #架構 #平台 最後照顧 07-14