[Mỗi ngày 1 open-source] #5 - oRPC: Sự tiến hóa của kiến trúc API Type-safe, kết hợp hoàn hảo RPC và REST

Chào mọi người, nếu bạn đã từng mê mẩn sự tiện lợi của tRPC (không cần viết fetch, tự động gợi ý code từ Backend sang Frontend) nhưng lại "đau đầu" khi muốn xuất file Swagger cho đối tác hoặc tích hợp với các hệ thống non-TypeScript, thì oRPC chính là "chân ái" mà bạn đang tìm kiếm.

Giới thiệu chung

oRPC không chỉ là một thư viện, nó là một bộ toolkit (bộ công cụ) hiện đại được thiết kế để xây dựng các API có tính an toàn kiểu dữ liệu (Type-safe) tuyệt đối. Triết lý của oRPC là: "Viết một lần, dùng mọi nơi". Bạn định nghĩa logic ở Server, và ngay lập tức Client có Autocomplete, trong khi thế giới bên ngoài vẫn thấy một hệ thống REST API chuẩn chỉnh.

Github: https://github.com/unrobot/orpc

Ngôn ngữ chủ đạo: TypeScript (100% Type-inference)

Kiến trúc: Plugin-based, Multi-runtime (Node.js, Bun, Deno, Edge Functions).

🏗️ Những điểm sáng về kiến trúc và kỹ thuật

1. Kiến trúc "Agnostic" và Tiêu chuẩn Web

oRPC không "giam cầm" bạn trong một hệ sinh thái hẹp.

• Schema Agnostic: Bạn thích dùng Zod? Tốt. Bạn muốn Valibot cho nhẹ? Ok. Hay ArkType để tối ưu runtime? oRPC cân hết nhờ hỗ trợ chuẩn Standard Schema.
• Edge-ready: Dự án hoàn toàn dựa trên Web Standards (Fetch API, Request, Response). Điều này có nghĩa là bạn có thể mang oRPC chạy trên Cloudflare Workers hay Vercel Edge mà không lo lỗi thư viện hệ thống.

2. Sự giao thoa giữa RPC và REST

Đây là điểm ăn tiền nhất. oRPC cung cấp trải nghiệm Developer của tRPC (gọi hàm trực tiếp) nhưng vẫn giữ được khả năng tương thích OpenAPI.

• Native OpenAPI: Tự động sinh file swagger.json cực kỳ chi tiết từ chính các Router của bạn.
• Minify Contract: oRPC có kỹ thuật trích xuất chỉ phần "xương sống" (kiểu dữ liệu và schema) để gửi sang Client. Điều này giúp bundle size cực nhẹ và không bao giờ bị lộ logic xử lý phía Server hay các mã bí mật (secrets).

3. Khả năng xử lý dữ liệu phức tạp (Native Hydration)

Hầu hết các thư viện RPC chỉ truyền tải được JSON thuần túy (string, number). Với oRPC:

• Bạn có thể gửi một đối tượng Date, một file Blob, hay File trực tiếp qua API.
• Hệ thống tự động băm nhỏ, gắn Metadata và phục hồi (hydrate) về đúng kiểu dữ liệu ban đầu ở phía nhận mà không cần cấu hình thêm superjson rườm rà.

🔄 Luồng hoạt động (Workflow Diagram)

Dưới đây là sơ đồ mô tả cách oRPC vận hành từ lúc định nghĩa đến khi thực thi và xuất bản tài liệu:

Phân tích sơ đồ:

1. Giai đoạn thiết kế: Bạn viết code, oRPC lo phần tài liệu (OpenAPI).
2. Giai đoạn thực thi: Request đi qua hệ thống Interceptor 3 lớp (Adapter -> Root -> Client) để đảm bảo an ninh và log dữ liệu.
3. Giai đoạn tiêu thụ: Frontend dùng các tích hợp như @orpc/tanstack-query để tận dụng sức mạnh của caching và đồng bộ hóa trạng thái.

💻 Ví dụ thực tế: Định nghĩa API cực nhanh

// Định nghĩa router trên Server
const router = os.router({
  getUser: os
    .input(z.object({ id: z.string() }))
    .handler(async ({ input, ctx }) => {
      return { id: input.id, name: "Viblo User", createdAt: new Date() };
    }),
});

// Ở Frontend, bạn có Type-safety 100%
const { data } = orpc.getUser.useQuery({ id: '1' });
console.log(data?.createdAt instanceof Date); // true - Tự động hydrate!

⚖️ So sánh với các giải pháp khác

✅ Kết luận: Tại sao nên chọn oRPC?

1. Dành cho tương lai: Nếu bạn đang build app bằng Next.js, Nuxt hoặc các Edge Platform, oRPC là lựa chọn tối ưu nhất hiện nay.
2. Không sợ Vendor Lock-in: Bạn có thể chuyển đổi giữa các thư viện validation hoặc framework server một cách dễ dàng.
3. Developer Experience (DX): Tốc độ Type-check nhanh hơn tRPC trong các dự án lớn nhờ kiến trúc tối ưu hóa kiểu dữ liệu.

Hy vọng bài viết Day 5 này mang lại cho bạn một công cụ "sắc bén" để nâng cấp hệ thống API của mình. Đừng quên Upvote và Follow mình để đón xem dự án mã nguồn mở "xịn xò" tiếp theo vào ngày mai nhé!