Descripción general
Cliente HTTP seguro basado en RxJS para TypeScript y adaptador opcional de Next.js/RSocket.
@byeolnaerim/typed-rx-httpes un cliente HTTP que inyecta tipos de Paths estilo OpenAPI, verificando tipos para URL, método HTTP, parámetros de ruta/query y cuerpo de solicitud, y devuelve resultados como Observable de RxJS.
Lo que quería de esta biblioteca no era una abstracción HTTP elaborada. Era poder importar y llamar directamente a las funciones generadas sin tener que reescribir la URL y los DTO de solicitud/respuesta que acabo de escribir en el backend.
Forma básica de uso de Core
El flujo básico consiste en preparar tipos de Paths estilo OpenAPI, crear HeaderStore si es necesario, generar el cliente con createHttpClient<Paths>() y llamar a callApi<R>(). El generador automático de servicios o el backend de WebFlux no son requisitos obligatorios para este flujo.
El tipo de solicitud se determina en Paths, y el tipo de respuesta es elegido por el llamador en callApi<R>(). No se obliga a un ResponseWrapper específico. NDJSON, caché CSR, autenticación de sesión, y las funcionalidades de Next.js y RSocket se añaden solo si es necesario.
Historia de origen
Uso Next.js y TypeScript en el frontend, y Java y WebFlux en el backend. Al crear un proyecto con esta combinación, había demasiadas repeticiones de contenido en ambos lados.
En el backend, se crean entidades y DTO de solicitud/respuesta y se escriben endpoints. Sin embargo, para llamar a ese endpoint en el frontend, tenía que volver a escribir la URL y crear un tipo o interfaz casi idéntica al DTO del backend. Para ser honesto, no era diferente de volver a escribir lo que había hecho en el backend en el frontend.
Esta repetición no solo aumenta la cantidad de código, sino que también aumenta la posibilidad de omitir cambios en los campos o URL de un lado cuando cambian. Por lo tanto, sentí la necesidad urgente de generar de manera predecible el código del cliente HTTP del frontend a partir de las especificaciones de la API REST del backend.
En ese proceso, apliqué primero el prototipo para el backend en nplauction.comreactive-mongo-dslywebflux-fe-dev-assistantel prototipo de typed-rx-http en el frontend. typed-rx-http no comenzó como una idea separada desde el principio, sino que surgió como una biblioteca adicional al crear el webflux-fe-dev-assistant y desarrollar lo que necesitaba en el frontend.
Forma de uso en proyectos de generación automática de Swagger.
En proyectos que utilizan la generación automática de servicios Swagger, en el código de la pantalla createHttpClientno escribo la URL cada vez. Solo creo commonService.tsse crea una vez un adaptador HTTP público de propiedad del proyecto y se importan solo las funciones de servicio generadas en OpenAPI. commonService.ts no es el nombre de archivo generado por la biblioteca, sino el nombre de archivo que define el proyecto, y se puede revisar el código completo en la documentación de inicio/HTTP Client.
const response = await firstValueFrom(
workplacesSearch({ params: { keyword: "kim" } }),
);El código anterior no contiene cadenas de URL ni interfaces de respuesta escritas manualmente. La URL, el método HTTP, el tipo de parámetro y el tipo de respuesta están incluidos en el servicio generado. Una respuesta se recibe como firstValueFromy las solicitudes que tienen múltiples valores, como el progreso de una tarea, se pueden recibir comosubscribe.
¿Dónde encajaría mejor?
Si el backend y el frontend están separados y el backend puede proporcionar unswagger.jsonválido, se puede reducir el trabajo repetitivo en el frontend de TypeScript. Si se utiliza un endpoint funcional de Java WebFlux, se puede combinar con webflux-fe-dev-assistant para conectar desde la generación de documentación hasta la creación de servicios.
typed-rx-http Core no depende de WebFlux. Es compatible con TypeScript que cumple con la especificación OpenAPI, independientemente de la implementación del backend. rutas Si hay un tipo, se puede usar para reducir la necesidad de escribir manualmente la URL de cadena y el tipo de solicitud cada vez. El cliente RSocket se puede usar directamente en el punto de entrada /rsocket, y solo se puede usar el generador AsyncAPI en proyectos que requieren la generación automática de servicios de ruta/solicitud/respuesta.
swagger.json oasyncapi-rsocket.jsondebería ser lo primero que verifique.