Overview
Type-safe RxJS-based HTTP client for TypeScript with optional Next.js/RSocket adapters
@byeolnaerim/typed-rx-httpis an HTTP client that injects OpenAPI-style Paths types to validate the URL, HTTP method, path/query parameters, and request body while making requests, returning the results as an RxJS Observable.
What I wanted from this library was not an elaborate HTTP abstraction. It was to import and call the generated functions directly without rewriting the URL and request/response DTOs that I just created on the backend.
Core Basic Usage
The basic flow is to prepare an OpenAPI-style Paths type, create a HeaderStore if necessary, then create a client with createHttpClient<Paths>() and call callApi<R>(). Automatic service generators or WebFlux backends are not mandatory for this flow.
The request type is determined by Paths, and the response type is chosen by the caller of callApi<R>() as R. Specific ResponseWrapper is not enforced. NDJSON, CSR cache, session auth, Next.js, and RSocket features are added only if needed.
Origin story
I use Next.js and TypeScript on the frontend, and Java and WebFlux on the backend. While creating projects with this combination, I found myself repeating the same content on both sides too often.
On the backend, I create entities and request/response DTOs and write endpoints. However, to call that endpoint from the frontend, I had to retype the URL and create almost the same type or interface as the backend DTO. To be honest, it was no different from rewriting what I had already written on the backend.
This repetition not only increases the amount of code but also raises the possibility of missing changes on one side when fields or URLs change. Therefore, I felt a strong need to generate the backend's REST API specifications predictably into the frontend HTTP client code.
In that process, I first applied the prototypes of the backend for the actual project nplauction.comreactive-mongo-dslandwebflux-fe-dev-assistantthe prototype of typed-rx-http on the frontend. typed-rx-http was not started as a separate idea from the beginning, but rather emerged as a supplementary library while creating the necessary pairs for the frontend while developing webflux-fe-dev-assistant.
Usage in Swagger auto generation projects.
In projects using Swagger service auto generation, the screen code uses createHttpClientI do not write the URL every time. I create commonService.tsa common HTTP adapter owned by the project, created once, and only imports the service functions generated from OpenAPI. commonService.ts is not the file name generated by the library but the file name determined by the project, and the full code can be checked in the Getting Started/HTTP Client documentation.
const response = await firstValueFrom(
workplacesSearch({ params: { keyword: "kim" } }),
);The above code does not contain URL strings or manually written response interfaces. The URL, HTTP method, parameter type, and response type are included in the generated service. A single response can be received as firstValueFromand requests with multiple values, like progress updates, can be received assubscribe.
Where would it fit best?
If the backend and frontend are separated and the backend can provide validswagger.jsonyou can reduce repetitive work in the TypeScript frontend. If you use Java WebFlux functional endpoints, you can connect from documentation generation to service creation using webflux-fe-dev-assistant.
typed-rx-http Core is not dependent on WebFlux. It is compatible with TypeScript regardless of backend implementation. paths If there is a type, it can be used to reduce the need to manually write string URLs and request types each time. The RSocket client can be used directly at the /rsocket entry point, and the AsyncAPI generator can be additionally used only in projects that require automatic generation of route/request/response services.
swagger.json Orasyncapi-rsocket.json.