Tổng quan
Giải thích bối cảnh và nguyên tắc của việc loại bỏ nút thắt khi phát triển đồng thời backend và frontend, viết lại hợp đồng API và loại hai lần, và chuyển đổi công việc phát triển lặp lại như router·handler·chuỗi trường MongoDB thành tạo dựa trên nguồn.
Câu chuyện nguồn gốc
Tôi làm việc với backend và frontend cùng nhau. Khi tạo một tính năng, tôi đã viết endpoint và request/response DTO trong Java WebFlux, và sau đó lại phải viết cùng URL và kiểu TypeScript ở frontend. Để điều chỉnh tài liệu Swagger, tôi đã phải chuyển thông tin đã có trên backend sang định dạng khác một lần nữa.
nút thắt lớn nhất là quá trình viết lại hợp đồng API do backend tạo ra thành dạng mà frontend có thể sử dụng. Nếu bất kỳ URL, phương thức HTTP, tham số path/query hoặc cấu trúc request/response nào bị sửa đổi khác nhau ở cả hai bên, tôi đã phát hiện ra vấn đề muộn hơn so với biên dịch. Vấn đề không chỉ đơn giản là phiền phức, mà sự không nhất quán do cùng một nội dung được quản lý hai lần bởi con người là vấn đề lớn hơn.
Tôi cũng muốn giảm thiểu việc lặp lại khi tạo mới RouterFunction và handler. Nếu tôi thêm tham chiếu như ApiAccountHandler::search vào router, tôi nghĩ rằng ít nhất khung class và method handler không tồn tại có thể được tạo tự động.
Vì vậy, việc tạo Swagger/OpenAPI, tạo khung handler và tạo enum trường entity đã được thực hiện trước, và sau đó khi sử dụng RSocket, tôi cũng đã thêm việc tạo AsyncAPI. Mặc dù mỗi cái có vẻ như là ý tưởng riêng biệt, nhưng điểm khởi đầu là giống nhau. Đó là việc không để con người viết lại những sự thật đã được ghi lại trong mã nguồn backend, mà để công cụ phát triển tự động tạo ra những phần mà máy có thể đọc.
Triết lý phát triển
dựa trên mã nguồn backend
Sử dụng thông tin đã có trong RouterFunction, handler, DTO và entity làm nguồn gốc cho tài liệu API và mã được tạo. Điều cốt lõi là không quản lý cùng một hợp đồng trong tệp riêng biệt.
chọn tự động hóa trong giai đoạn phát triển hơn là phép thuật thời gian chạy
không phải là framework chặn yêu cầu sản xuất mà phân tích nguồn trong môi trường phát triển local và tạo tệp thực tế. Có thể kiểm tra kết quả bằng mắt và quản lý phiên bản.
tuân theo quy tắc dự đoán của dự án
không đặt mục tiêu là một trình biên dịch tổng quát hiểu tất cả mã Java. Tôi ưu tiên phân tích cấu trúc endpoint chức năng WebFlux mà tôi thực sự sử dụng theo quy tắc rõ ràng.
loại bỏ các đoạn kết nối lặp lại
tạo Swagger từ endpoint backend, và trình tạo frontend đọc tài liệu đó để tạo service và type, kết nối tất cả thành một chuỗi tự động.
Đọc gì từ backend
nguồn RouterFunction
Đọc phương thức HTTP, đường dẫn lồng nhau, tham chiếu phương thức xử lý và predicate.
Nguồn xử lý
Đọc body yêu cầu, giá trị truy vấn/đường dẫn và loại nhà xuất bản phản hồi.
Request / Response DTO
Kết nối loại Java đã viết sẵn trên backend với schema OpenAPI.
Nguồn thực thể Mongo
Đọc tên raw lưu trữ của trường Java và @Field, collection của @Document.
Bộ điều khiển RSocket
Đọc route @MessageMapping và loại payload yêu cầu/đáp ứng.
Tạo cái gì thay vì viết lại
Tuy 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ả OpenAPI
Tạo hợp đồng API cho endpoint REST để dịch vụ front-end và trình tạo loại TypeScript có thể sử dụng.
asyncapi-rsocket.json
Tạo hợp đồng cho route RSocket và payload để trình tạo client RSocket front-end có thể đọc.
Nguồn xử lý
Tạo và điều chỉnh khung class và phương thức dựa trên tham chiếu handler đã ghi trong RouterFunction.
Enum {Entity}Fields
Tạo enum cho tên trường Java và tên raw lưu trữ của thực thể để không lặp lại tên trường chuỗi.
Enum CollectionNames
Tạo để có thể sử dụng tên collection được khai báo trong @Document thay cho chuỗi.
Luồng tự động trong dự án hiện tại
• Viết RouterFunction, handler và DTO yêu cầu/đáp ứng Java trên backend.
• Watcher của profile local phát hiện thay đổi nguồn và cập nhật swagger.json hoặc asyncapi-rsocket.json.
• Script tạo @byeolnaerim/typed-rx-http của front-end đọc tài liệu và tạo hàm dịch vụ cùng loại TypeScript.
• Trong mã màn hình, không cần viết lại URL và loại phản hồi mà chỉ cần import hàm đã tạo để sử dụng.
• Khi thực thể thay đổi, enum trường sử dụng trong truy vấn và enum collection cũng được cập nhật.