Our Journey with Caching

Vercel · 2024 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Vercel vừa làm framework Next.js vừa bán nền tảng chạy nó; nhận định về sản phẩm của họ trong trang này đều là "theo Vercel". Bài giải thích hướng đi, chưa phải tính năng ổn định.

Bối cảnh

• Theo Vercel, nút thắt frontend phổ biến nhất là waterfall client-server. App Router đưa fetch về server (Server Components, một round-trip), nhưng server đôi khi phải dynamic; Partial Prerendering ra đời để giữ cả tốc độ tải đầu lẫn dữ liệu động.
• Cái giá nằm ở cache: fetch() mặc định bị cache nên prototype và app rất động khó chịu; truy cập DB không qua fetch() thì không có công cụ kiểm soát; unstable_cache() kém tiện, nên phải thêm cấu hình cấp segment (dynamic, revalidate...) làm lối thoát.

Thay đổi chính

• Chế độ thử nghiệm chỉ còn <Suspense> và use cache. Khi component dùng dữ liệu, cookie, header, giờ hay số ngẫu nhiên thì build báo lỗi buộc chọn:
  • Động: bọc <Suspense>; không có gì bị cache ngầm, vỏ trang vẫn tức thì.
  • Tĩnh: use cache ở page hay layout; trang render tĩnh.
  • Lai: use cache ở layout, phần động trong page, hoặc use cache trên từng hàm async (khoá gồm tham số và biến closure).
• cacheTag() + revalidateTag() để vô hiệu hoá (gắn tag được sau khi có dữ liệu); cacheLife() cho vòng đời theo mức "seconds" đến "max".
• Thay đổi gây vỡ chính: bỏ cache fetch() mặc định.

Bài học cho SWE

• Cache ngầm tăng tốc nhưng gây bất ngờ; bắt người viết nói rõ "động hay cache" ngay chỗ dùng dữ liệu.

Liên quan

• Vercel 2025 · Vercel 2026 · Vercel 2022
• Cache và invalidation · Kiến trúc frontend