ภาพรวม

วิธีการใช้งาน Core เบื้องต้น

กระบวนการพื้นฐานคือการเตรียมประเภท OpenAPI-style Paths และหากจำเป็นให้สร้าง HeaderStore จากนั้นสร้าง client ด้วย createHttpClient<Paths>() และเรียก callApi<R>() การสร้าง service อัตโนมัติหรือ WebFlux backend ไม่ใช่ข้อกำหนดที่จำเป็นสำหรับกระบวนการนี้

ประเภทคำขอจะถูกกำหนดจาก Paths และประเภทการตอบกลับจะถูกเลือกโดย R ของ callApi<R>() โดยผู้เรียก ไม่บังคับให้ใช้ ResponseWrapper เฉพาะ NDJSON, CSR cache, session auth, ฟังก์ชันของ Next.js และ RSocket จะถูกเพิ่มเฉพาะเมื่อจำเป็นเท่านั้น

เรื่องราวต้นกำเนิด

ผมใช้ Next.js และ TypeScript ที่ frontend และใช้ Java และ WebFlux ที่ backend การสร้างโปรเจกต์ด้วยการรวมกันนี้ทำให้ต้องเขียนเนื้อหาซ้ำกันมากเกินไป

ที่ backend จะสร้าง entity และ request/response DTO และเขียน endpoint แต่ที่ frontend ต้องพิมพ์ URL ใหม่และสร้าง type หรือ interface ที่เกือบจะเหมือนกับ DTO ของ backend อีกครั้ง ต้องบอกว่าเหมือนกับการเขียนสิ่งที่ผมทำที่ backend อีกครั้งที่ frontend

การทำซ้ำแบบนี้ไม่เพียงแต่เพิ่มปริมาณโค้ด แต่ยังเพิ่มโอกาสที่จะลืมอัปเดตฟิลด์หรือ URL ที่เปลี่ยนไปในอีกด้านหนึ่ง ดังนั้นจึงรู้สึกถึงความจำเป็นในการสร้าง REST API สเปคของ backend ให้สามารถคาดการณ์ได้ในโค้ด HTTP client ของ frontend

ในกระบวนการนั้นได้ใช้โปรโตไทป์สำหรับ backend ที่ nplauction.comreactive-mongo-dslและwebflux-fe-dev-assistantโปรโตไทป์ของ typed-rx-http ที่ frontend ก่อน typed-rx-http ไม่ได้เริ่มต้นจากแนวคิดที่แยกต่างหาก แต่เกิดขึ้นจากการสร้าง webflux-fe-dev-assistant และสร้างสิ่งที่จำเป็นสำหรับ frontend ไปพร้อมกัน

วิธีการใช้งานในโปรเจกต์ที่สร้างอัตโนมัติด้วย Swagger

ในโครงการที่ใช้การสร้างบริการ Swagger อัตโนมัติ จะมีการสร้างโค้ดหน้าจอจาก createHttpClientไม่ต้องเขียน URL ทุกครั้ง ในโปรเจกต์จะ commonService.tsสร้าง HTTP adapter สาธารณะของเจ้าของโครงการหนึ่งครั้ง และนำเข้าเฉพาะฟังก์ชันบริการที่สร้างจาก OpenAPI มาใช้ commonService.ts ไม่ใช่ชื่อไฟล์ที่สร้างโดยไลบรารี แต่เป็นชื่อไฟล์ที่โครงการกำหนด และสามารถตรวจสอบโค้ดทั้งหมดได้จากเอกสารเริ่มต้น/HTTP Client.

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

ในโค้ดข้างต้นไม่มี URL string หรือ interface ของ response ที่เขียนด้วยตนเอง URL, HTTP method, parameter type และ response type จะรวมอยู่ใน service ที่สร้างขึ้น การตอบสนองครั้งเดียวจะได้รับผ่าน firstValueFromและคำขอที่มีค่าหลายค่าต่อเนื่องกันเช่นสถานะการทำงานจะได้รับผ่านsubscribeสามารถรับได้

จะเหมาะสมที่สุดที่ไหน

หาก backend และ frontend แยกออกจากกันและ backend สามารถให้แต่ผมไม่ต้องการให้ typed-rx-http ถูกใช้เฉพาะใน WebFlux เท่านั้น แม้ว่า backend จะไม่สร้าง Swagger โดยตรง แต่หากมี TypeScript ที่ตรงตาม OpenAPI สเปค ก็สามารถลดการเขียน URL สตริงและ request type ด้วยมือได้ RSocket client ก็ถูกสร้างขึ้นตามเหตุผลเดียวกันโดยอิงจากเอกสาร AsyncAPIสามารถลดการทำงานซ้ำใน frontend ที่ใช้ TypeScript ได้ หากใช้ Java WebFlux functional endpoint สามารถเชื่อมต่อการสร้างเอกสารไปจนถึงการสร้าง service ได้ด้วย webflux-fe-dev-assistant

typed-rx-http Core ไม่ขึ้นอยู่กับ WebFlux ไม่ว่าจะเป็นการใช้งานด้านหลังใด ๆ TypeScript ที่เข้ากันได้กับข้อกำหนด OpenAPI ไลบรารีนี้ได้รับการตรวจสอบในโปรเจกต์ nplauction.com ที่ใช้ Next.js + WebFlux ก่อน ผมคิดว่ามันสามารถใช้ใน backend อื่น ๆ ได้เพราะแยกเป็นโมดูลอิสระ แต่ไม่ได้ตรวจสอบผลลัพธ์จากทุก framework และเครื่องมือสร้าง OpenAPI จริง ๆ แล้วควรตรวจสอบโครงสร้างของ หากมี type สามารถใช้เพื่อลดการเขียน URL สตริงและประเภทคำขอด้วยมือในทุกครั้งได้ RSocket client สามารถใช้ได้โดยตรงจาก /rsocket และสามารถใช้ AsyncAPI generator เพิ่มเติมได้เฉพาะในโครงการที่ต้องการการสร้างบริการ route/request/response อัตโนมัติเท่านั้น.

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