花園

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

• 程式碼走讀：一個 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
• 自動儲存 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