Tổng quan

Cách sử dụng cơ bản của Core

Quy trình cơ bản là chuẩn bị kiểu OpenAPI-style Paths, nếu cần thì tạo HeaderStore, sau đó tạo client bằng createHttpClient<Paths>() và gọi callApi<R>(). Tự động tạo service hoặc backend WebFlux không phải là điều kiện cần thiết cho quy trình này.

Loại yêu cầu được xác định từ Paths, và loại phản hồi được chọn bởi R trong callApi<R>(). Không bắt buộc phải có ResponseWrapper cụ thể. NDJSON, cache CSR, xác thực phiên, và tính năng Next.js và RSocket chỉ được thêm vào khi cần thiết.

Câu chuyện nguồn gốc

Tôi sử dụng Next.js và TypeScript ở frontend, và Java cùng WebFlux ở backend. Khi tạo dự án với sự kết hợp này, tôi đã phải viết lại rất nhiều nội dung giống nhau ở cả hai bên.

Ở backend, tôi tạo entity và DTO request/response, và viết endpoint. Nhưng để gọi endpoint đó từ frontend, tôi lại phải gõ lại URL và tạo lại kiểu hoặc interface gần giống với DTO backend. Nói thật, việc viết lại những gì tôi đã viết ở backend từ frontend không khác gì mấy.

Sự lặp lại này không chỉ làm tăng số lượng mã, mà còn làm tăng khả năng bỏ sót khi một bên thay đổi trường hoặc URL. Vì vậy, tôi cảm thấy cần thiết phải tạo ra mã client HTTP frontend một cách dự đoán được từ đặc tả REST API backend.

Trong quá trình đó, tôi đã áp dụng prototype cho backend trên dự án thực tế nplauction.com.reactive-mongo-dslvàwebflux-fe-dev-assistantprototype của typed-rx-http cho frontend. typed-rx-http không phải là một ý tưởng hoàn toàn tách biệt từ đầu, mà là một thư viện phát sinh khi tôi tạo webflux-fe-dev-assistant và cùng tạo ra các cặp cần thiết cho frontend.

Cách sử dụng trong dự án tạo tự động Swagger

Trong dự án sử dụng tự động tạo dịch vụ Swagger, createHttpClienttôi không viết lại URL mỗi lần. Tôi chỉ tạo một lần cho dự án và import các hàm dịch vụ được tạo ra từ Swagger. commonService.tstạo một HTTP adapter công cộng thuộc sở hữu dự án và chỉ cần import các hàm dịch vụ được tạo từ OpenAPI để sử dụng. commonService.ts không phải là tên tệp do thư viện tạo ra mà là tên tệp do dự án quy định, và bạn có thể kiểm tra toàn bộ mã trong tài liệu bắt đầu/HTTP Client.

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

Mã trên không có chuỗi URL hay interface response được viết thủ công. URL, phương thức HTTP, type tham số và type response đều được bao gồm trong dịch vụ đã tạo. Một phản hồi sẽ được nhận qua firstValueFromvà các yêu cầu có nhiều giá trị nối tiếp như tiến trình công việc sẽ được nhận quasubscribe.

Nơi nào sẽ phù hợp nhất?

Nếu backend và frontend được tách biệt và backend có thể cung cấpTuy nhiên, tôi không muốn chỉ sử dụng typed-rx-http cho WebFlux. Ngay cả khi backend không tạo Swagger trực tiếp, nếu có kiểu TypeScript phù hợp với đặc tả OpenAPIthì bạn có thể giảm thiểu công việc lặp lại từ frontend TypeScript. Nếu bạn sử dụng endpoint functional Java WebFlux, bạn có thể kết hợp với webflux-fe-dev-assistant để kết nối từ việc tạo tài liệu đến việc tạo dịch vụ.

typed-rx-http Core không phụ thuộc vào WebFlux. TypeScript tương thích với OpenAPI specification bất kể cách triển khai backend. Phạm vi hiện tại đã được xác nhận Nếu có type, có thể sử dụng để giảm bớt việc viết tay URL chuỗi và loại yêu cầu mỗi lần. RSocket client có thể được sử dụng trực tiếp từ điểm vào /rsocket, và chỉ có thể sử dụng AsyncAPI generator trong các dự án cần tự động tạo route/request/response service.

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