Làm chủ Bun.js: Runtime JavaScript hiệu năng cao cho các API hiện đại và công cụ CLI

Tại sao Server Production của tôi bị nghẽn

Tôi đang nhìn vào bảng điều khiển Grafana lúc 2:13 sáng. Các biểu đồ độ trễ trông như một dãy núi nhấp nhô. Microservice nội bộ của chúng tôi, xử lý khoảng 5.000 báo cáo được tạo từ CLI mỗi giờ, đang gặp bế tắc. Node.js đã là lựa chọn hàng đầu của tôi suốt một thập kỷ qua. Tuy nhiên, chi phí khởi động và dung lượng bộ nhớ khổng lồ của node_modules đang làm cạn kiệt tài nguyên của chúng tôi. Mỗi khi một serverless function được kích hoạt, khoảng thời gian “cold start” dài 800ms cảm giác như vô tận.

Đêm đó, tôi đã chuyển một trong những công cụ CLI phụ của mình sang Bun.js. Kết quả đến ngay lập tức. Thời gian khởi tạo giảm từ 500ms xuống chỉ còn 42ms. Bun không chỉ là một framework khác; nó là một sự tái tư duy hoàn chỉnh về runtime JavaScript. Nó được xây dựng từ đầu bằng ngôn ngữ Zig và vận hành bởi engine JavaScriptCore. Bằng cách sử dụng cùng một engine giúp Safari đạt tốc độ cao, Bun loại bỏ phần lớn sự phân mảnh thường thấy trong hệ sinh thái Node.

Chi phí hạ tầng ngày càng tăng trong khi sự kiên nhẫn của người dùng ngày càng giảm. Việc sử dụng một runtime tích hợp sẵn trình đóng gói (bundling), kiểm thử (testing) và thực thi trong một file binary duy nhất không còn là điều xa xỉ nữa. Đó là một sự cần thiết để kiểm soát hóa đơn cloud.

Cài đặt Bun.js trên máy của bạn

Node thường yêu cầu một trình quản lý phiên bản như NVM chỉ để giữ cho mọi thứ ổn định. Ngược lại, Bun là một file thực thi duy nhất và độc lập. Nó không kéo theo một “vali” đầy các dependency nặng nề. Đây là cách tôi thiết lập khi cần một môi trường mới chỉ trong vài giây.

Cài đặt trên Linux và macOS

Với hầu hết các môi trường Unix-like, một script curl đơn giản sẽ xử lý các công việc nặng nhọc. Tôi sử dụng lệnh này trên các máy dev Ubuntu và MacBook Pro của mình:

curl -fsSL https://bun.sh/install | bash

Sau khi script chạy xong, hãy source file .zshrc hoặc .bashrc để cập nhật đường dẫn (path). Tôi thường chỉ cần khởi động lại terminal để đảm bảo lệnh bun đã sẵn sàng.

Thiết lập trên Windows

Hỗ trợ Windows hiện đã là bản native và cực kỳ ổn định. Nếu bạn đang dùng Windows 10 hoặc 11, hãy chạy lệnh này trong PowerShell để cài đặt trực tiếp:

powershell -c "irm bun.sh/install.ps1 | iex"

Nếu bạn thích các trình quản lý gói, cả Scoop và Homebrew đều hoạt động hoàn hảo. Bạn sẽ muốn thấy một số phiên bản rõ ràng khi chạy lệnh kiểm tra.

# Kiểm tra cài đặt
bun --version

Cấu hình dự án Bun đầu tiên của bạn

Tôi đã chuẩn bị tinh thần cho một cuối tuần dài để tái cấu trúc khi lần đầu chuyển đổi dự án. Nhưng tôi đã lầm. Bun được thiết kế như một sự thay thế trực tiếp (drop-in replacement) cho Node.js. Nó đọc file package.json, tôn trọng node_modules của bạn và triển khai các API Node gốc như fs và path.

Khởi tạo dự án

Bắt đầu bằng cách tạo một thư mục mới. Bỏ qua npm init và sử dụng trình khởi tạo gốc thay thế:

mkdir fast-api && cd fast-api
bun init

Lệnh này mang tính tương tác và rất hữu ích. Nó tạo ra các file package.json, tsconfig.json và index.ts. Bun hỗ trợ TypeScript mặc định (first-class). Bạn có thể nói lời tạm biệt với ts-node hoặc các cấu hình Babel phức tạp. Bạn viết TypeScript và nó chỉ việc chạy.

Quản lý gói: Không còn phải chờ đợi

Tôi đã từng mất hàng giờ mỗi tháng để chờ npm install. Trong một pipeline CI/CD, những phút đó rất đắt đỏ. Trình quản lý gói của Bun sử dụng hardlink và bộ nhớ đệm (cache) toàn cục để tránh tải xuống lặp lại. Nó nhanh hơn khoảng 20 lần so với npm trong hầu hết các kịch bản.

# Thay vì dùng npm install express
bun add express

Tôi đã thấy bun install hoàn tất trong 0,4 giây trên các dự án mà npm mất hơn 15 giây. Nếu bạn làm việc trong một monorepo, sự tăng tốc này sẽ thay đổi toàn bộ quy trình phát triển của bạn.

Xác minh và Giám sát trên Production

Chạy một script cục bộ thì dễ, nhưng một API production đòi hỏi sự khắt khe hơn. Chúng ta cần xác minh rằng Bun thực sự mang lại hiệu suất như hứa hẹn dưới tải trọng lớn.

Xây dựng một API tốc độ cao

API Bun.serve gốc nhanh hơn đáng kể so với Express. Nó bỏ qua lớp stream cũ của Node.js để giảm chi phí vận hành. Đây là một dịch vụ kiểm tra sức khỏe (health-check) đơn giản mà tôi thường xuyên triển khai:

// index.ts
const server = Bun.serve({
  port: 3000,
  fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/") return new Response("Bun đang bay!");
    if (url.pathname === "/health") {
      return new Response(JSON.stringify({ status: "ok", memory: process.memoryUsage().rss }), { 
        headers: { "Content-Type": "application/json" } 
      });
    }
    return new Response("Không tìm thấy", { status: 404 });
  },
});

console.log(`Server đang chạy trên cổng ${server.port}`);

Bạn không cần bước build để chạy file này. Chỉ cần sử dụng:

bun index.ts

Giám sát hiệu năng và Hot Reloading

Sử dụng cờ --hot trong quá trình phát triển. Không giống như nodemon (vốn khởi động lại toàn bộ tiến trình và xóa cache), Bun thực hiện nạp lại trong bộ nhớ (in-memory reload). Nó giữ cho tiến trình luôn chạy và chỉ thay thế phần code bị thay đổi. Điều này làm cho vòng lặp phản hồi (feedback loop) có cảm giác tức thì.

bun --hot index.ts

Hãy để ý đến Resident Set Size (RSS) – bộ nhớ thực tế – trên production. Trong các bài kiểm tra của tôi, Bun thường sử dụng 30MB RAM cho một API cơ bản, trong khi Node.js sử dụng 120MB. Bạn có thể giám sát việc này qua lệnh top hoặc bằng cách đẩy log sang một dịch vụ như Datadog. Để kiểm thử, trình chạy (runner) tích hợp sẵn của Bun tương thích với Jest nhưng hoàn thành trong một khoảng thời gian cực ngắn.

# Chạy bộ test suite của bạn với tốc độ tối đa
bun test

Kết luận

Bạn không cần phải xóa các dự án Node.js hiện có ngay hôm nay. Tuy nhiên, đối với các công cụ CLI mới, edge functions hoặc các API lưu lượng cao, những lợi ích mang lại là quá lớn để có thể bỏ qua. Việc hợp nhất trình đóng gói, trình chạy và trình quản lý gói vào một công cụ duy nhất giúp việc gỡ lỗi (debug) trở nên đơn giản hơn rất nhiều.

Hãy thử chuyển một script tiện ích sang Bun trong tuần này. Hãy xem thời gian pipeline CI của bạn giảm đi một nửa. Một khi bạn trải nghiệm thời gian khởi động 40ms, việc quay lại các runtime cũ mang lại cảm giác như đang đi lùi. Bản thân tôi của phiên bản 2 giờ sáng chắc chắn sẽ không bao giờ nhìn lại phía sau.