mrkt的程式學習筆記

過去工作專案大多使用 RabbitMQ 來處理訊息佇列，RabbitMQ 的幾種模式（Direct, Topic, Fanout）都有使用，因為都可以解決大多數的應用情境，所以就沒有想要去使用 Kafak，畢竟多建立一套服務就需要再多花時間去維護。

一直以來也想要找個時間來玩玩 Kafka，於是就利用週末時間學習怎麼使用 Docker 架設服務，程式開發練習怎麼使用 Confluent.Kafka，這是一篇學習筆記。

前一篇「使用 Wolverine 實作生產者-消費者模式（Producer-Consumer Pattern）」介紹了將原本使用 Channels + BackgroundService 的生產者-消費者模式改用 Wolverine  來實作。

就以現實的問題來看，如果服務是相當頻繁地被使用時，如果 MessageCreatedEventHandler 消費者的處理速度有所延遲，那麼 Channels 裡就會堆積大量的 MessageCreatedEvent 事件，一旦服務出現問題而重新啟動或是有版本更新而需要重新部署，那麼佇列在 Channels 裡的事件就會消失不見了，這可是不得了的事情。所以這篇就來用 WolverineFx.RabbitMQ，生產者將事件發送到 RabbitMQ 裡，然後消費者再去接收存放在 RabbitMQ 裡的訊息，如此的改變就是為了避免因為服務重新啟動而讓佇列在 Channels 裡的事件消失不見。

之前寫了一篇「使用 Channels 與 BackgroundService 實作生產者-消費者模式（Producer-Consumer Pattern）」是使用 Channels 與 BackgroundService 來實作，而這一次就來改用 Wolverine 這個套件來試試看。

有關 Wolverine 這個套件我也看了好久，一直想拿來試試看，會想要用這個套件，主要是它是一個輕量化的工具，適合用於整合訊息佇列、事件驅動設計和後台任務處理。

而且也因為適合用於整合訊息佇列、事件驅動設計，所以支援了許多第三方服務，例如：RabbitMQ, Kafaka, MQTT, AzureServiceBux, AmazonSqs 等，所以打算之後也繼續玩玩 Wolverine。

從 .NET Framework  開發 WebApi 服務時就開始使用 Swagger UI，直到現在都已經是直接在預設的 ASP.NET Core WebApi 專案範本裡就包含在內。

但是…  我一直都覺得 Swagger UI 做為 API 文件工具並不是很好閱讀，要查看輸入參數或輸出資料格式內容都不是那麼方便，我想大家或多或少應該都有這樣的感覺，所以我都還會在專案裡安裝 ReDoc 套件，ReDoc 做為 API 文件工具來檢視 API 的輸出入各種資訊都相當直觀且清楚，比 Swagger UI 更好閱讀，但是 ReDoc 只是個單純的 API 文件檢視工具，無法在 ReDoc 裡測試執行 API。

所以之前看到 Scalar 這個新的 API 文件檢視工具時就讓我眼睛一亮，有著如同 ReDoc 一般的 UI 外觀，可以方便且直覺地查看 API Endpoints 的資訊，而且還可以直接在上面測試執行 API，所以就趕緊來試試看。

其實這也不一定是在整合測試才會用到，一般會呼叫使用到外部 API 時的情境也一樣適用。

當要將一個物件的資料帶入 QueryString 時，每次就會覺得這個步驟很麻煩，甚至有一段時間是自己寫個方法來處理，但總覺得不是一個漂亮的解決方式，

於是就想到可以使用 Flurl 來處理，也的確是可以簡化以前那些繁瑣的建立 QueryString 的作法。

在 2015 年 12 月裡所舉行的 twMVC#21，我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家，而到了現在才有時間將使用、安裝的說明給整理出來，所以將會有一系列的文章說明如何使用 NanoProfiler。

經過兩篇文章的鋪陳，總算來到了最後一篇，將會把修改過的最後完成版提供給各位，讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。

ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2

接續上一篇的內容，來看看最原始的做法有些什麼樣的問題，先開門見山做個說明，這一篇會再沿用別人所提供的改良做法，不過最後的結果依舊還是會有一些問題存在，所以最後在第三篇的文章裡將會提供我所修改過的程式碼，而這也是我開發的專案以及部門其他開發團隊所使用的方法。

在開發過程中，開發人員主要還是會透過 Postman 進行開發的偵錯、測試、操作等，如果開發人員只有一個人的時候，在 Postman 裡增加或管理 Collection, API 都還算是可以控制，但如果是多人開發團隊共同開發一個 Web API 專案時，就會發現到每個人所使用的 API Collection 內容都有很大的出入與差異，所以就必須要有一個能夠一致化 API Collection 的功能，讓團隊的每個開發人員都使用一樣的 API Collection 進行操作。

前一篇簡單介紹如何在一個 ASP.NET Web Api 專案裡安裝 Swashbuckle - Swagger for Web Api 這個套件，基本上都沒有什麼難度，特別要注意的就是 Controller 與 Action 方法與相關類別的 XML 文件註解要記得寫以及維護，在一般的使用情況下的 Api 服務資訊提供已經相當清楚了。

不過提供更加清楚的資訊給使用 Api 服務的開發者對於產品的開發與溝通是有絕對幫助的，但老實說，要把 Swagger 寫得好又要能夠搭配 Web Api 後端程式讓資訊可以自動產生，其實也不是容易的事情，這邊就來說明幾個調整顯示資訊的做法。