概述
用於 TypeScript 的基於 RxJS 的類型安全 HTTP 客戶端和可選的 Next.js/RSocket 適配器
@byeolnaerim/typed-rx-http是通過注入 OpenAPI 風格的 Paths 類型來檢查 URL、HTTP 方法、路徑/查詢參數和請求主體的類型，並將請求結果作為 RxJS Observable 返回的 HTTP 客戶端。
我在這個庫中想要的並不是宏大的 HTTP 抽象，而是能夠直接導入生成的函數並調用，而不必在前端再次編寫剛剛在後端編寫的 URL 和請求/響應 DTO。
Core 基本使用方式
基本流程是準備 OpenAPI 風格的 Paths 類型，必要時創建 HeaderStore，然後使用 createHttpClient<Paths>() 創建客戶端並調用 callApi<R>()。自動服務生成器或 WebFlux 後端不是此流程的必要條件。
請求類型由 Paths 決定，響應類型由調用者選擇 callApi<R>() 的 R。特定的 ResponseWrapper 也不強制要求。NDJSON、CSR 快取、session auth、Next.js 和 RSocket 功能僅在需要時添加。
起源故事
我在前端使用 Next.js 和 TypeScript，後端則使用 Java 和 WebFlux。由於這種組合，我發現兩邊重複編寫相同內容的情況太多了。
在後端創建實體和請求/響應 DTO 並編寫端點。但是在前端調用該端點時，必須重新輸入 URL，並且還需要創建幾乎相同的類型或介面。坦白說，這與在前端再次編寫我在後端編寫的內容沒有什麼區別。
這種重複不僅增加了代碼量，還增加了當一方的字段或 URL 變更時，另一方可能被遺漏的風險。因此，我迫切感受到需要將後端的 REST API 規範預測性地生成到前端 HTTP 客戶端代碼中。
在這個過程中，我在實際項目 nplauction.com 中首先應用了後端的reactive-mongo-dsl和webflux-fe-dev-assistant的原型，前端則首先應用了 typed-rx-http 的原型。typed-rx-http 並不是從一開始就作為一個獨立的想法開始，而是在創建 webflux-fe-dev-assistant 的過程中，與前端所需的配對一起創建的附加庫。
在 Swagger 自動生成項目中的使用方式
在使用 Swagger 服務自動生成的專案中，從畫面代碼中 createHttpClient不會每次都編寫 URL。項目中只需 commonService.ts創建一個專案擁有的公共 HTTP 適配器，並僅導入從 OpenAPI 生成的服務函數來使用。commonService.ts 不是庫生成的檔案名稱，而是專案自定義的檔案名稱，可以在開始/HTTP 客戶端文檔中先查看完整代碼。
const response = await firstValueFrom(
workplacesSearch({ params: { keyword: "kim" } }),
);上述代碼中沒有 URL 字串或手動編寫的響應介面。URL、HTTP 方法、參數類型和響應類型包含在生成的服務中。一次響應是 firstValueFrom接收的，像工作進度一樣多個值連續的請求可以用subscribe來接收。
在哪裡最合適呢
如果後端和前端是分開的，並且後端能提供有效的swagger.json，則可以減少 TypeScript 前端的重複工作。如果使用 Java WebFlux 功能端點，則可以組合 webflux-fe-dev-assistant 來連接從文檔生成到服務生成。
typed-rx-http Core 不依賴於 WebFlux。無論後端實現如何，與 OpenAPI 規範兼容的 TypeScript paths 如果有類型，可以用來減少每次手動編寫字符串 URL 和請求類型的工作。RSocket 客戶端可以直接在 /rsocket 入口點使用，並且僅在需要路由/請求/響應服務自動生成的專案中可以額外使用 AsyncAPI 生成器。
swagger.json 或asyncapi-rsocket.json的結構。