ASP.NET Core 提供了健康檢查的 Middleware，可以讓我們很輕鬆的知道應用程式目前的本身的狀態以及應用程式所依賴其他服務的狀態；也可以讓容器協調器進行重新啟動容器或是暫停服務，比如 K8s 的 Liveness、Readiness
令人驚喜的是 AspNetCore.HealthChecks.UI 提供 UI / Alert 讓監視系統變得更有效率了
Serilog 已經是我們團隊的標準的 Log Provider，在此我針對它的配置粗略的紀錄，希望可以幫助到需要的人
以往我們在 .Net Fx 可以透過 Transforms 來切換不同的組態，而在 .NET Core 開始，則改用 Microsoft.Extensions.Configuration 來處理組態，上篇 也針對 Microsoft.Extensions.Configuration 進行了介紹，這篇將針對 .NET 應用程式注入環境的做法做一個簡單的介紹
當你的服務需要隱藏真實的訊息給調用端時，除了在每一個 Action 各自處理，Middleware 也是選擇之一，本想這應該是很簡單的操作，沒想到碰了一鼻子灰，以下是我複寫 HttpContext.Response.Body 的步驟，希望對正觀看的你有幫助。
在介接其他人寫的 Web API 時，可以透過 Mock Server 來模擬對方會回傳的資料，比如說 json-server，但這樣往往會因為兩造之間沒有一個合約、規範，各自實作，導致最後在整合的時落差太大；理論上，雙方基於合約、規範，進行開發，最後在整合的時候應該有問題的狀況應該會小一點，Prism 是套基於 Swagger/OpenAPI Specification 的 Mock Server，在 OpenAPI 的生態系裡面算是蠻完整的解決方案之一，接下來，是我對它在使用上的小小心得。
當我們的 Swagger / OpenAPI Specification 寫到某一個程度就會開始想要模組化、重用它，例如，當 components/schemas 節點需要被其他的檔案參照。
以往，在 ASP.NET Fx / ASP.NET Core 我會先寫好 Controller(Server Code) 再搭配 NSwag、Swashbuckle.AspCore 產生 Swagger / OpenAPI Specification Doc，一旦要修改它(Spec.)就必須要重新編譯專案，只是要改文件的錯字，也沒有動到 Server Code 的邏輯，卻要重新 Build Server，幾次下來發現這樣似乎不是很聰明。也常常發生過於關注 Server Code 忽略 Specification ，導致兩邊跟不一致。
現在，我先寫 Specification，然後再透過它產生 Controller (Server Code) 讓 Specification 不再強制依賴 Server Code，解除強依賴關係，編寫規範時再也不需要重新建置專案，目前運作起來挺順暢的，接下來，我分享我是怎麼做的
若我們直接存取雲端資源，將面臨到帳單的問題；若隔離雲端資源，那隔離的成本將會大大的增加，也不利於整合測試，因此有很多的開源專案模擬出了這些網路服務，只要在本地開發環境安裝模擬器，就可以盡情的享受開發的樂趣，大大的降低雲端費用，好好地善用它們吧，搜尋關鍵字 AWS S3 Simulation/Emulation、Local S3，就可以找到不少資源。
Razor Engine 是一種 .NET 腳本語言和引擎，主要是為文本範本開發，這跟我們在寫 ASP.NET MVC Razor 語法是一樣的，現在我想要透過 Razor 來定義 Template，透過 Data Binding 產生各種不同的結果。在調查有哪些 Razor 套件可以在 .NET 6 下運行且可以完整支援 Razor 語法，最後我選用 RazorTemplating，他骨子裡面則是使用 Razor Class Library
驗證替使用者建立身分識別，授權則是用來判斷使用者能不能使用某一個功能，ASP.NET Core 提供許多的授權 Role、Claims、Policy 等，老實講 Policy 授權使用上有一點門檻，分享一下我的實際用法，也給需要的人參考