花園

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

• 程式碼走讀：一個 jobs handler 的解剖 jobs queue 的觀念篇講了鐵律，這篇拿 newsletter 確認信的 handler 當標本，看鐵律在程式碼裡長什麼樣。 註冊與進入點 ts newsletter-mail.handler.ts（節錄） onApplicationBootstrap(): void { this.jobs.registerHa…⇄ 2#程式碼走讀 #nestjs #平台 最後照顧 07-14
• 程式碼走讀：一個 decorator 從標記到落庫的旅程 後台每個寫入端點掛著 @Audit(...) 就會自動留稽核紀錄。decorator 看起來像魔法，拆開只有三站：標記 → 讀取 → 執行。 第一站：decorator 只是貼標籤 ts audit.decorator.ts export const AUDITMETADATAKEY = 'audit:options'…⇄ 2#程式碼走讀 #nestjs #平台 最後照顧 07-14
• 程式碼走讀：一個 getter 如何讓 repository 自動加入交易 交易傳染那篇講了概念，這篇看實作——整個機制的魔法濃縮在一個 getter 裡。 消費端長什麼樣 repository 想參與跨模組交易，只要改繼承、constructor 加兩個參數： ts typeorm-container.repository.ts @Injectable() export class Type…⇄ 1#程式碼走讀 #nestjs #ddd 最後照顧 07-14
• e2e 打真 postgres：拋棄式資料庫與兩條 schema 路徑 SQLite 退場後，e2e 測試改打真 postgres。幾個實作決策值得記錄： 拋棄式資料庫 每輪 e2e 建一個帶亂數後綴的資料庫、跑完即棄。比起共用一個測試庫加清空表格，拋棄式的好處是絕對隔離——併發跑兩套測試不互踩、失敗現場可以留著驗屍、永遠不會有「上一輪的髒資料讓這一輪偶爾紅」的靈異事件。代價是本機要有一個…⇄ 3#測試 #nestjs #資料庫 最後照顧 07-14
• Windows 的 preserve-symlinks 死亡陷阱：NestJS 被載入了兩份 Monorepo 遷移後最兇的一個雷，症狀完全不知所云： Nest can't resolve dependencies of ... ModuleRef Nest can't resolve dependencies of ... ConfigService DI 容器說找不到 ConfigService——但它明明…⇄ 2#踩雷 #nestjs #windows 最後照顧 07-14
• 一場 429 假扮 404 的偵探記：限流的讀寫分道 症狀：在自己的網站上點了幾篇文章，突然看到「找不到這則筆記」。筆記明明在。重新整理，又好了。 追兇 第一層：錯誤頁誤導。頁面把所有 API 失敗都當成 404 呈現——真兇是 429（請求太多），被謊報成「不存在」。訪客會以為內容被刪了，這比錯誤本身更糟。教訓：錯誤分流要誠實，429/500 與 404 是完全不同的故…⇄ 4#踩雷 #nuxt #nestjs 最後照顧 07-14
• 自動儲存 vs 稽核紀錄：折疊窗口的取捨 後台的每個寫入端點都掛稽核——誰、什麼時候、對誰、做了什麼成功的操作，一列一筆。這套機制撞上筆記編輯器的自動儲存時，出了一個好問題：打字停頓 1.5 秒就存一次，寫一小時的文章＝幾百筆「編輯筆記」稽核，其他真正重要的動作（發佈、刪除）全被洗掉了。 選項與抉擇 不記編輯？那「已發佈的文章事後被改過」這種真正有稽核價值的事…⇄ 4#nestjs #平台 #架構 最後照顧 07-14
• 結緣、澆灌與一封確認信：匿名網站的信任設計 這個站沒有會員系統——訪客是匿名的。但有兩個功能需要「某種程度的身分」：訂閱常青通知，和澆灌的一人一票。怎麼在不建帳號的前提下設計信任，是我在這個站上最喜歡的一組取捨。 訂閱：double opt-in 填了信箱不算訂閱，點了確認信裡的連結才算。這不是形式主義：沒有這一步，任何人都能拿別人的信箱亂訂，你的系統就成了騷擾…⇄ 7#rootnote #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
• AsyncLocalStorage 交易傳染：跨模組交易不髒手 跨模組交易是 DDD 分層最容易破功的地方。倉儲系統的一個業務動作要同時動三個模組：容器標記入庫、儲位保留、任務建立——三筆寫入必須同生共死。傳統解法是把 EntityManager 當參數一路傳下去，於是 ORM 概念滲進每一個 domain port 的簽名，四層白分了。 解法：把交易綁在異步鏈上 Node 的 A…⇄ 4#ddd #nestjs #架構 最後照顧 07-14
• 四層 DDD：domain 層一行框架都不准碰 我的每個後端模組都是同一個四層結構，而整套架構只有一條不可協商的鐵律：domain/ 是純 TypeScript，零框架依賴。NestJS 與 TypeORM 只准出現在 application 層以下。 modules/<module/ ├── domain/ entities / value-objects / e…⇄ 5#ddd #架構 #nestjs 最後照顧 07-14