Ở bài đầu tiên trong series này, tôi đã giải thích vì sao các đội nên thống nhất một contract OpenAPI trước khi ai bắt tay vào viết mã. Bài này nói về công cụ giúp cái contract đó thực sự phát huy tác dụng: Orval.
Tự tay viết lớp gọi API cho frontend là một trong những việc chẳng ai dám nhận là mình thích. Bạn copy type từ tài liệu của backend, viết đi viết lại cái wrapper cho request lần thứ bốn mươi, rồi ba tuần sau có ai đó đổi tên một field và thế là một nửa số chỗ gọi API của bạn âm thầm hỏng. Orval xóa sổ luôn công việc đó. Chỉ cần trỏ nó tới OpenAPI spec, Orval sẽ generate mã client cho bạn: hàm có type cho từng endpoint, model khớp chính xác với contract, và cả mock để bạn phát triển trước khi backend kịp làm xong.
Vì sao đội frontend thích Orval#
Phần generate mock là phần bị đánh giá thấp nhất. Một khi spec đã chốt, frontend có thể dựng một máy chủ giả rồi làm toàn bộ giao diện dựa trên nó, thay vì ngồi chờ những endpoint lúc nào cũng “sắp xong rồi”. Khi backend thật được deploy, bạn chỉ việc trỏ client sang đó và gần như mọi thứ chạy được luôn, vì cả hai bên đều làm dựa trên cùng một tài liệu.
Cái lợi còn lại là phần mã nhàm chán giờ đúng ngay từ khi được sinh ra. Không còn ai gõ nhầm tên field trong một request body tự viết, vì đơn giản là chẳng còn ai phải tự viết request body nữa.
Vì sao đội backend cũng thích#
Khi spec là nguồn sự thật duy nhất, những trao đổi hằng ngày giữa hai bên cũng thay đổi hẳn. Thay vì những thread chat kiểu “endpoint này trả về gì ấy nhỉ?”, frontend chỉ việc đọc các type đã được generate. Lập trình viên backend ít bị làm phiền hơn, mà lại nhận được góp ý sớm hơn: nếu frontend làm dựa trên mock rồi thấy API có chỗ nào khó dùng, bạn sẽ biết ngay từ lúc sửa còn rẻ, chứ không phải đợi đến khi nó đã lên production.
Orval nằm ở đâu trong quy trình làm việc#
Chẳng có gì cầu kỳ cả. Backend đề xuất spec, hai đội cùng review, frontend dùng Orval để generate client và mock rồi bắt đầu làm, còn backend thì implement các endpoint thật theo đúng contract đó. Khi spec thay đổi, cả hai bên generate lại, và compiler sẽ chỉ ra chính xác chỗ nào bị hỏng. Phần cuối đó mới là mấu chốt: những chỗ lệch nhau giữa frontend và backend sẽ hiện ra thành lỗi compile, thay vì thành lỗi trên production.
Đây không phải loại công cụ hào nhoáng gì. Nó chỉ lặng lẽ dẹp bỏ cả một kiểu tranh cãi giữa các đội, và lần nào có cơ hội đổi như vậy, tôi cũng sẵn lòng.