Aperçu

Client HTTP typé basé sur RxJS pour TypeScript et adaptateur Next.js/RSocket optionnel.

@byeolnaerim/typed-rx-httpest un client HTTP qui injecte des types de chemins de style OpenAPI, vérifie les types pour l'URL, la méthode HTTP, les paramètres de chemin/requête et le corps de la requête, et renvoie les résultats sous forme d'Observable RxJS.

Ce que je voulais dans cette bibliothèque n'était pas une abstraction HTTP complexe. C'était d'importer et d'appeler directement les fonctions générées sans avoir à réécrire l'URL et les DTO de requête/réponse que je venais d'écrire côté backend.

Méthode d'utilisation de base de Core

Le flux de base consiste à préparer des types de chemins de style OpenAPI, à créer un HeaderStore si nécessaire, puis à générer un client avec createHttpClient<Paths>() et à appeler callApi<R>(). Le générateur de service automatique ou le backend WebFlux ne sont pas des conditions préalables à ce flux.

Le type de requête est déterminé par Paths, et le type de réponse est choisi par l'appelant dans R de callApi<R>(). Aucun ResponseWrapper spécifique n'est imposé. NDJSON, cache CSR, authentification de session, et les fonctionnalités Next.js et RSocket ne sont ajoutés que si nécessaire.

La génération automatique OpenAPI est une fonctionnalité optionnelle.

Le script Node automatique qui crée des types TypeScript et des fichiers de service à partir de JSON Swagger/OpenAPI est une fonctionnalité optionnelle distincte du client HTTP Core. Les utilisateurs typiques de Core, /next, /rsocket n'ont pas besoin d'exécuter le générateur.

Histoire d'origine

J'utilise Next.js et TypeScript côté frontend, et Java et WebFlux côté backend. En créant un projet avec cette combinaison, j'ai constaté que je devais souvent répéter les mêmes éléments des deux côtés.

Côté backend, je crée des entités et des DTO de requête/réponse et écris des endpoints. Mais pour appeler cet endpoint côté frontend, je devais retaper l'URL et créer à nouveau des types ou interfaces presque identiques aux DTO du backend. Pour être honnête, cela revenait à réécrire ce que j'avais déjà fait côté backend.

Cette répétition n'augmente pas seulement la quantité de code, mais augmente également la probabilité d'oublier de mettre à jour l'autre côté si un champ ou une URL change. J'ai donc ressenti le besoin urgent de générer de manière prévisible le code client HTTP du frontend à partir des spécifications de l'API REST du backend.

Dans ce processus, j'ai d'abord appliqué le prototype pour le backend sur le projet réel nplauction.comreactive-mongo-dsletwebflux-fe-dev-assistantle prototype de typed-rx-http pour le frontend. typed-rx-http n'est pas né d'une idée distincte, mais plutôt comme une bibliothèque qui a émergé en créant des éléments nécessaires pour le frontend tout en développant webflux-fe-dev-assistant.

Méthode d'utilisation dans un projet de génération automatique Swagger.

Dans un projet utilisant la génération automatique de service Swagger, createHttpClientje n'écris pas à chaque fois l'URL. Je crée une fois commonService.tsvous créez une fois un adaptateur HTTP public possédé par le projet, et vous n'importez que les fonctions de service générées par OpenAPI.

const response = await firstValueFrom(
  workplacesSearch({ params: { keyword: "kim" } }),
);

Le code ci-dessus ne contient pas de chaîne d'URL ou d'interface de réponse écrite manuellement. L'URL, la méthode HTTP, le type de paramètre et le type de réponse sont inclus dans le service généré. Une réponse unique est reçue par firstValueFromet les requêtes avec plusieurs valeurs, comme l'état d'avancement d'une tâche, peuvent être reçues parsubscribe.

Où cela conviendrait-il le mieux ?

Si le backend et le frontend sont séparés et que le backend peut fournir unswagger.jsonvalide, vous pouvez réduire le travail répétitif dans le frontend TypeScript. Si vous utilisez un point de terminaison fonctionnel Java WebFlux, vous pouvez combiner avec webflux-fe-dev-assistant pour relier la génération de documentation à la création de services.

typed-rx-http Core n'est pas dépendant de WebFlux. TypeScript compatible avec les spécifications OpenAPI, chemins s'il y a un type, il peut être utilisé pour réduire le travail d'écriture manuelle de l'URL de chaîne et du type de requête à chaque fois. Le client RSocket peut être utilisé directement à partir du point d'entrée /rsocket, et l'AsyncAPI generator peut être utilisé uniquement dans les projets nécessitant la génération automatique de service route/request/response.

Plage actuellement vérifiée

Le résultat de la génération peut varier en fonction de la structure de la documentation OpenAPI ou AsyncAPI et de l'outil de génération utilisé. Il n'y a aucune garantie sur la sortie de tous les frameworks et outils de génération de documentation, donc vérifiez le résultat généré avant de l'appliquer.swagger.json ougithub.com/joohyoungkim19940805/typed-rx-httpasyncapi-rsocket.json

Repo : Le flux d'utilisation réel consiste en trois étapes : recevoir Swagger, générer le service et appeler la fonction générée.