Jamstack là gì? Kiến trúc tách rời nơi API của bạn là sản phẩm

Nếu bạn đã triển khai một trang web tĩnh lấy dữ liệu trực tiếp từ một vài dịch vụ, bạn đã dùng gần đúng mô hình Jamstack. Kiến trúc này hiển thị trước giao diện người dùng, phục vụ tài sản tĩnh qua CDN và đưa mọi phần động sang các lệnh gọi API. Thuật ngữ này được Netlify phổ biến khoảng năm 2015; tên gọi có thể đã cũ, nhưng cách xây dựng phía sau nó vẫn là nền tảng của nhiều ứng dụng web hiện đại.

Dùng thử Apidog ngay hôm nay

Jamstack thực sự là viết tắt của cái gì?

Jamstack là viết tắt của JavaScript, API và Markup.

• JavaScript chạy trong trình duyệt để xử lý phần động: gọi dữ liệu, xác thực, cập nhật UI.
• API thay thế backend nguyên khối. Bất kỳ phần nào không được render sẵn sẽ được lấy qua HTTP.
• Markup là HTML được build trước và phục vụ như tệp tĩnh.

Cốt lõi của Jamstack gồm hai quyết định kỹ thuật:

1. Pre-render trước khi deploy: build HTML, CSS, JS và assets trước.
2. Tách frontend khỏi backend: frontend chỉ giao tiếp với các dịch vụ thông qua API.

Luồng triển khai thường wygląda như sau:

Source code + CMS/API data
        ↓
Build step
        ↓
Static HTML/CSS/JS
        ↓
CDN
        ↓
Browser
        ↓
Runtime API calls khi cần dữ liệu động

Cách hoạt động của sự tách biệt

Trong kiến trúc truyền thống, request thường đi theo đường này:

Browser → App server → Database → Render HTML → Browser

Frontend, backend, render logic và truy cập dữ liệu thường nằm trong cùng một ứng dụng.

Với Jamstack, luồng được tách ra:

Browser → CDN → Static files
Browser → API → CMS / payment / search / auth / custom backend

Frontend là một bundle tĩnh. Nó không truy cập trực tiếp database. Khi cần dữ liệu, nó gọi API. API đó có thể là:

• headless CMS
• dịch vụ thanh toán
• dịch vụ tìm kiếm
• backend tự viết
• SaaS bên thứ ba

Lợi ích thực tế:

• CDN phục vụ static files nhanh và ổn định.
• Backend service có thể thay đổi độc lập.
• Các nhóm có thể sở hữu từng service riêng.
• Frontend không phụ thuộc vào một app server duy nhất.

Đánh đổi là bạn phải quản lý tốt hợp đồng API. Khi frontend chỉ biết backend thông qua API, thay đổi response sai cấu trúc có thể làm hỏng UI.

Đây cũng là tư duy đằng sau API-như-một-sản-phẩm. Khi API là giao diện mà frontend và các nhóm khác xây dựng dựa vào, nó không còn là chi tiết triển khai. Đó là lý do phần mềm ngày càng trở nên headless và API trở thành sản phẩm.

Dữ liệu thời gian xây dựng so với dữ liệu thời gian chạy

Quyết định quan trọng nhất trong Jamstack là: dữ liệu được lấy khi build hay khi người dùng mở trang?

	Dữ liệu thời gian xây dựng	Dữ liệu thời gian chạy
Khi chạy	Một lần trong quá trình build	Mỗi lần tải trang hoặc khi người dùng tương tác
Phù hợp cho	Blog, tài liệu, danh mục sản phẩm, nội dung ít thay đổi	Giỏ hàng, hồ sơ người dùng, giá, dữ liệu cá nhân hóa
Cách phục vụ	Tích hợp vào HTML tĩnh trên CDN	Fetch qua JavaScript gọi API
Đánh đổi	Có thể cũ cho đến lần build tiếp theo	Tải lần đầu có thể chậm hơn, phụ thuộc API live

Ví dụ với dữ liệu build-time:

// Ví dụ ý tưởng: lấy bài viết trong bước build
export async function getStaticProps() {
  const posts = await fetch("https://cms.example.com/posts").then((res) =>
    res.json()
  );

  return {
    props: { posts },
  };
}

Ví dụ với dữ liệu runtime:

// Ví dụ ý tưởng: lấy giỏ hàng theo người dùng trong trình duyệt
async function loadCart() {
  const res = await fetch("/api/cart", {
    headers: {
      Authorization: `Bearer ${token}`,
    },
  });

  if (!res.ok) {
    throw new Error("Không thể tải giỏ hàng");
  }

  return res.json();
}

Cách chọn nhanh:

• Nội dung giống nhau cho mọi người dùng → lấy lúc build.
• Nội dung cá nhân hóa hoặc thay đổi liên tục → lấy lúc runtime.
• Nội dung cần SEO tốt nhưng thay đổi định kỳ → cân nhắc build lại theo lịch hoặc theo webhook.
• Tính năng phụ thuộc đăng nhập → gọi API từ client hoặc thông qua serverless/edge function.

Hầu hết dự án thực tế sẽ dùng cả hai. Bạn pre-render những gì có thể, rồi gọi API cho những gì không thể render trước.

Bộ công cụ trong thực tế

Một stack Jamstack thường có các phần sau:

Static site generator / meta-framework
        ↓
Build output
        ↓
CDN / hosting platform
        ↓
APIs / serverless / edge functions

Các công cụ phổ biến gồm Gatsby, Hugo, Jekyll, Eleventy và Next.js. Chúng giúp render trước trang, tạo output tĩnh và triển khai lên CDN hoặc nền tảng hosting.

Dữ liệu thường đến từ nhiều nguồn:

• CMS quản lý nội dung
• API thương mại điện tử
• API tìm kiếm
• API xác thực
• backend nội bộ
• SaaS bên thứ ba

Không service nào trong số đó render toàn bộ trang. Chúng chỉ phơi bày dữ liệu qua API. Frontend chịu trách nhiệm kết nối các API đó thành trải nghiệm người dùng.

Nếu mô hình này nghe giống phương pháp MACH, đó là vì hai hướng tiếp cận này có nhiều điểm giao nhau. MACH là viết tắt của Microservices, API-first, Cloud-native và Headless. Jamstack tập trung nhiều hơn vào cách build và phân phối frontend; MACH tập trung nhiều hơn vào cách lắp ráp backend từ các service độc lập.

Jamstack phù hợp ở đâu ngày nay

Với tư cách thuật ngữ marketing, Jamstack đã giảm độ phổ biến. Netlify đã loại bỏ nhãn này khỏi định vị cốt lõi vào năm 2023 và chuyển sang thông điệp “web có thể kết hợp”. Khảo sát State of Jamstack cũng kết thúc vào năm 2024 vì cộng đồng đã chuyển hướng.

Nhưng thực hành kỹ thuật thì vẫn còn:

• pre-render markup
• phục vụ static assets qua CDN
• dùng API cho dữ liệu động
• tách frontend khỏi backend
• tích hợp nhiều service độc lập

Các framework như Next.js đã làm mờ ranh giới bằng cách thêm lại server-side rendering, server components và nhiều mô hình render khác. Vì vậy, Jamstack “thuần tĩnh” ít phổ biến hơn. Tuy nhiên, nguyên tắc chính vẫn giữ nguyên: frontend là client, còn tính năng đến từ API.

Chất lượng API trong kiến trúc tách biệt

Jamstack đẩy phần động vào API. Vì vậy, hợp đồng API là thứ frontend phụ thuộc trực tiếp.

Đây là nơi Apidog hữu ích. Apidog không phải CMS, hosting platform hay framework Jamstack. Nó là lớp giúp thiết kế, mô phỏng, kiểm thử và tài liệu hóa API trong quy trình API-first.

Một quy trình thực tế có thể như sau:

1. Thiết kế hợp đồng API trước

Định nghĩa endpoint, request, response và error format trước khi frontend hoặc backend bắt đầu implement.

Ví dụ contract đơn giản theo OpenAPI:

openapi: 3.0.0
info:
  title: Product API
  version: 1.0.0
paths:
  /products:
    get:
      summary: Lấy danh sách sản phẩm
      responses:
        "200":
          description: Danh sách sản phẩm
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  required:
                    - id
                    - name
                    - price
                  properties:
                    id:
                      type: string
                    name:
                      type: string
                    price:
                      type: number

Cách này phù hợp với phát triển API-first: thống nhất hợp đồng trước, implement sau.

2. Mock API trước khi backend hoàn tất

Với mock servers, frontend có thể gọi dữ liệu giả lập theo contract.

Ví dụ frontend có thể bắt đầu tích hợp ngay:

const products = await fetch("https://mock.example.com/products").then((res) =>
  res.json()
);

Điều này giúp frontend và backend làm việc song song thay vì chờ nhau.

3. Kiểm thử API trong CI

Khi API là dependency của frontend tĩnh, lỗi contract cần được phát hiện trước khi deploy.

Ví dụ pipeline ý tưởng:

name: API checks

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  test-api:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run API tests
        run: |
          apidog run

Apidog CLI có thể chạy kiểm thử API ở chế độ headless trong pipeline. Mục tiêu là phát hiện response sai schema, status code sai hoặc contract bị phá vỡ trước khi frontend production gặp lỗi.

4. Giữ tài liệu đồng bộ

Trong kiến trúc tách biệt, tài liệu API không nên là file viết tay bị bỏ quên. Nó cần đi cùng contract, test và mock. Khi API thay đổi, frontend phải nhìn thấy thay đổi đó rõ ràng.

Hỗ trợ MCP của Apidog cũng cho phép tác nhân AI hoặc IDE làm việc trực tiếp với định nghĩa API của bạn.

Tóm lại: bạn vẫn tự chọn framework, hosting và kiến trúc. Apidog hỗ trợ lớp hợp đồng API mà kiến trúc đó phụ thuộc vào.

Các câu hỏi thường gặp

Jamstack có giống một trang web tĩnh không?

Không. Trang web tĩnh chỉ là HTML build sẵn không có dữ liệu động. Jamstack bắt đầu từ markup tĩnh nhưng thêm JavaScript và API cho phần động, ví dụ đăng nhập, giỏ hàng, tìm kiếm hoặc dữ liệu người dùng.

Jamstack đã chết chưa?

Thuật ngữ này đã giảm phổ biến, và Netlify đã loại bỏ nó khỏi marketing chính vào năm 2023. Nhưng các thực hành như pre-rendering, backend điều khiển bằng API và phân phối qua CDN vẫn rất phổ biến. Nhiều người hiện gọi đó là phát triển web hiện đại thay vì Jamstack.

Jamstack khác gì kiến trúc truyền thống?

Kiến trúc truyền thống thường render trang trên server được kết nối với database. Jamstack render trước trang thành static files và lấy dữ liệu động qua API. Frontend được tách khỏi backend, nên bạn có thể thay đổi service mà không cần viết lại toàn bộ UI.

API trong Jamstack thực sự làm gì?

API cung cấp mọi thứ không được render trước: nội dung, tìm kiếm, thanh toán, xác thực và dữ liệu người dùng. Vì frontend chỉ truy cập các phần đó qua API, contract rất quan trọng. Bạn có thể thiết kế và mô phỏng các API đó trước để các nhóm làm việc song song, rồi kiểm thử chúng trước khi triển khai.

Tổng kết

Jamstack là một kiến trúc tách biệt: pre-render markup, phục vụ qua CDN và xử lý phần động bằng API. Tên gọi có thể đã cũ, nhưng mô hình này đã trở thành một phần của phát triển web hiện đại.

Bài học thực tế cho developer là: khi frontend chỉ là client, API chính là sản phẩm.

Vì vậy, hãy đầu tư vào hợp đồng API: thiết kế trước, mock cho frontend, kiểm thử trong CI và giữ tài liệu đồng bộ. Tải xuống Apidog để thiết kế và mô phỏng các API mà frontend tách biệt của bạn phụ thuộc vào, hoặc đọc thêm về lý do vì sao API của bạn giờ đây là sản phẩm.