Übersicht

Grundlegende Verwendung von Core

Der grundlegende Ablauf besteht darin, OpenAPI-Style Paths-Typen vorzubereiten, gegebenenfalls einen HeaderStore zu erstellen und dann createHttpClient<Paths>() zu verwenden, um den Client zu erstellen und callApi<R>() aufzurufen. Ein automatischer Service-Generator oder ein WebFlux-Backend sind keine zwingenden Voraussetzungen für diesen Ablauf.

Der Anforderungstyp wird aus Paths bestimmt, und der Antworttyp wird von dem Aufrufer in callApi<R>() ausgewählt. Ein bestimmter ResponseWrapper wird ebenfalls nicht erzwungen. NDJSON, CSR-Cache, Sitzungsauthentifizierung, Next.js und RSocket-Funktionen werden nur hinzugefügt, wenn erforderlich.

Ursprungsgeschichte

Ich verwende im Frontend Next.js und TypeScript, während ich im Backend Java und WebFlux benutze. Bei der Erstellung des Projekts stellte ich fest, dass ich dieselben Inhalte auf beiden Seiten viel zu oft wiederholen musste.

Im Backend erstelle ich Entities und Request/Response DTOs und schreibe Endpunkte. Um diesen Endpunkt im Frontend aufzurufen, musste ich die URL erneut eintippen und fast denselben Typ oder das Interface wie das Backend erstellen. Um ehrlich zu sein, war es nicht anders, als das, was ich im Backend geschrieben hatte, im Frontend noch einmal zu schreiben.

Diese Wiederholungen erhöhen nicht nur die Menge an Code, sondern auch die Wahrscheinlichkeit, dass ich vergesse, eine Änderung an einem Feld oder einer URL auf der anderen Seite vorzunehmen. Daher fühlte ich dringend die Notwendigkeit, die REST-API-Spezifikationen des Backends vorhersehbar in den Frontend-HTTP-Client-Code zu generieren.

In diesem Prozess habe ich Prototypen für das Backend auf nplauction.com erstelltreactive-mongo-dslundwebflux-fe-dev-assistantund habe zuerst den Prototyp von typed-rx-http im Frontend angewendet. typed-rx-http begann nicht als separate Idee, sondern entstand eher als Nebenprodukt, während ich webflux-fe-dev-assistant entwickelte und die benötigten Paare für das Frontend erstellte.

Verwendung in Projekten mit automatischer Swagger-Generierung

In Projekten, die die automatische Erstellung von Swagger-Diensten verwenden, gibt es im Bildschirmcode createHttpClientschreibe ich nicht jedes Mal die URL. Ich erstelle einmal commonService.tsein gemeinsames HTTP-Adapter, das dem Projekt gehört, einmal zu erstellen und nur die aus OpenAPI generierten Dienstfunktionen zu importieren. commonService.ts ist kein von der Bibliothek generierter Dateiname, sondern ein vom Projekt festgelegter Dateiname, und im Dokument zur HTTP-Client-Implementierung können Sie den gesamten Code zuerst überprüfen.

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

Im obigen Code gibt es keine URL-Strings oder manuell erstellten Response-Interfaces. URL, HTTP-Methode, Parametertyp und Responsetyp sind im generierten Service enthalten. Eine einmalige Antwort wird empfangen werden. Dies ist derzeit die am häufigsten verwendete Methode im NPL-Projekt.empfangen, während mehrere Werte, die den Fortschritt einer Anfrage darstellen, überfirstValueFromempfangen werden können.

Wo passt es am besten?

Wenn Backend und Frontend getrennt sind und das Backend gültigeswagger.jsonbereitstellen kann, kann die Wiederholung im TypeScript-Frontend reduziert werden. Wenn Sie Java WebFlux-Funktionsendpunkte verwenden, können Sie webflux-fe-dev-assistant kombinieren, um die Dokumentationserstellung bis zur Serviceerstellung zu verbinden.

typed-rx-http Core ist nicht von WebFlux abhängig. Es ist mit TypeScript kompatibel, unabhängig von der Backend-Implementierung und der OpenAPI-Spezifikation. paths Wenn es einen Typ gibt, kann er verwendet werden, um die manuelle Eingabe von String-URLs und Anforderungstypen zu reduzieren. Der RSocket-Client kann direkt am /rsocket-Einstiegspunkt verwendet werden, und der AsyncAPI-Generator kann nur in Projekten verwendet werden, die eine automatische Erstellung von Routen/Anfragen/Antwortdiensten benötigen.

Repo: github.com/joohyoungkim19940805/typed-rx-http