Series 7 — Web Quality – Engineering

Bài 1: Authentication & Authorization – Xác thực và phân quyền trong ứng dụng web

1. Mở đầu

Khi xây dựng một ứng dụng web có chức năng đăng nhập, chúng ta thường nghĩ rằng chỉ cần tạo biểu mẫu nhập email, mật khẩu và kiểm tra thông tin người dùng là đủ. Tuy nhiên, trong một hệ thống thực tế, việc quản lý tài khoản còn liên quan đến nhiều vấn đề khác: người dùng đã đăng nhập hay chưa, họ được phép truy cập tài nguyên nào và làm thế nào để duy trì trạng thái đăng nhập một cách an toàn.

Ví dụ, trong một website quản lý sản phẩm, khách truy cập có thể xem danh sách sản phẩm, người dùng đã đăng nhập có thể tạo đơn hàng, còn quản trị viên có thể quản lý tài khoản và thay đổi thông tin sản phẩm.

Nếu ứng dụng chỉ ẩn những nút chức năng không phù hợp mà không kiểm tra quyền ở phía server, người dùng vẫn có thể gửi yêu cầu trực tiếp đến API để thực hiện hành động không được phép.

Để hiểu cách xây dựng những chức năng này, chúng ta cần nắm vững ba khái niệm: Authentication, Authorization và Session Management.

2. Authentication là gì?

Authentication, hay xác thực, là quá trình xác minh danh tính của một người dùng hoặc một thực thể đang truy cập hệ thống.

Trong ứng dụng web, Authentication thường xuất hiện khi người dùng đăng nhập bằng email và mật khẩu. Hệ thống kiểm tra thông tin xác thực và xác định tài khoản tương ứng.

Một số phương thức xác thực phổ biến gồm:

• Email và mật khẩu.
• Mã xác minh một lần (OTP).
• Đăng nhập bằng nhà cung cấp bên ngoài thông qua các giao thức phù hợp.
• Passkeys hoặc các phương thức xác thực không dùng mật khẩu.
• Xác thực đa yếu tố (MFA), kết hợp từ hai yếu tố xác thực trở lên.

Ví dụ, giao diện đăng nhập trong React có thể gửi thông tin đến API:

async function login(
  email: string,
  password: string
) {
  const response = await fetch("/api/login", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    credentials: "include",
    body: JSON.stringify({
      email,
      password,
    }),
  });

  if (!response.ok) {
    throw new Error("Đăng nhập thất bại");
  }

  return response.json();
}

Đây chỉ là phần gửi yêu cầu từ frontend. Backend vẫn phải kiểm tra thông tin đăng nhập, xác minh mật khẩu an toàn và tạo trạng thái xác thực phù hợp.

Frontend không nên tự quyết định rằng người dùng đã được xác thực chỉ vì biểu mẫu đã gửi thành công hoặc dữ liệu trả về có một trường success.

3. Authorization là gì?

Authorization, hay phân quyền, là quá trình xác định người dùng đã được xác thực có được phép thực hiện một hành động hoặc truy cập một tài nguyên cụ thể hay không.

Ví dụ trong hệ thống quản lý:

Vai trò	Quyền có thể được cấp
Khách	Xem nội dung công khai
Người dùng	Xem và chỉnh sửa dữ liệu của chính mình
Quản trị viên	Quản lý tài khoản và nội dung theo quyền được cấp

Trong thực tế, quyền truy cập không nhất thiết chỉ phụ thuộc vào vai trò. Hệ thống có thể cần kiểm tra quyền sở hữu tài nguyên, trạng thái tài khoản hoặc các điều kiện nghiệp vụ khác.

Ví dụ trong React

type User = {
  id: string;
  role: "user" | "admin";
};

function AdminPanel({ user }: { user: User }) {
  if (user.role !== "admin") {
    return <p>Bạn không có quyền truy cập.</p>;
  }

  return <button>Quản lý người dùng</button>;
}

Ví dụ này giúp điều chỉnh giao diện theo vai trò, nhưng không phải cơ chế bảo mật hoàn chỉnh.

Nếu người dùng tự sửa JavaScript, thay đổi dữ liệu trong trình duyệt hoặc gửi yêu cầu API trực tiếp, điều kiện trong component không thể bảo vệ tài nguyên ở phía server.

Vì vậy, frontend có thể ẩn hoặc hiện chức năng theo quyền, nhưng backend phải thực sự kiểm tra quyền trước khi thực hiện hành động được bảo vệ.

4. Phân biệt Authentication và Authorization

Hai khái niệm này có liên quan nhưng giải quyết hai câu hỏi khác nhau.

Tiêu chí	Authentication	Authorization
Câu hỏi chính	Bạn là ai?	Bạn được phép làm gì?
Mục đích	Xác minh danh tính	Kiểm tra quyền truy cập
Ví dụ	Đăng nhập thành công	Được phép xóa một sản phẩm
Thời điểm	Thường diễn ra khi đăng nhập hoặc xác thực lại	Diễn ra khi truy cập tài nguyên hoặc thực hiện hành động

Một người dùng có thể đăng nhập thành công nhưng vẫn không có quyền truy cập vào trang quản trị.

Ngược lại, nếu hệ thống không xác định được danh tính hoặc thông tin xác thực không hợp lệ, những hành động yêu cầu đăng nhập thường sẽ bị từ chối.

5. Session Management là gì?

Sau khi đăng nhập, ứng dụng cần duy trì trạng thái xác thực để người dùng không phải nhập lại mật khẩu trong mỗi yêu cầu.

Session Management là quá trình tạo, duy trì, gia hạn và kết thúc trạng thái phiên đăng nhập.

Một luồng hoạt động phổ biến:

1. Người dùng gửi thông tin đăng nhập.
2. Backend xác minh thông tin.
3. Backend tạo session và gửi cookie phiên cho trình duyệt.
4. Trình duyệt gửi cookie phù hợp trong những yêu cầu tiếp theo.
5. Backend kiểm tra session để xác định trạng thái xác thực.
6. Khi đăng xuất hoặc phiên hết hạn, session được kết thúc theo cơ chế của hệ thống.

Cookie thường chỉ chứa mã định danh phiên hoặc một thông tin xác thực phù hợp, không nên chứa mật khẩu người dùng.

Ví dụ, server có thể gửi cookie với các thuộc tính:

Set-Cookie: session=opaque-session-id; HttpOnly; Secure; SameSite=Lax; Path=/

Ý nghĩa của các thuộc tính:

• HttpOnly: JavaScript phía trình duyệt không thể đọc trực tiếp cookie đó.
• Secure: Cookie chỉ được gửi qua HTTPS trong điều kiện thông thường.
• SameSite: Kiểm soát việc cookie được gửi trong các ngữ cảnh yêu cầu khác site, góp phần giảm nguy cơ CSRF.
• Path: Xác định phạm vi đường dẫn mà cookie được gửi đến.

Trong hệ thống thực tế, session cần có thời hạn hợp lý, được vô hiệu hóa khi cần và được bảo vệ trước những rủi ro như đánh cắp hoặc cố định session.

6. Cookie, Session và Token khác nhau như thế nào?

Đây là những khái niệm thường bị nhầm lẫn.

Cookie là cơ chế lưu và gửi dữ liệu từ trình duyệt đến server theo những quy tắc nhất định.

Session là trạng thái phiên được hệ thống sử dụng để duy trì thông tin xác thực hoặc trạng thái của người dùng. Với mô hình session truyền thống, dữ liệu phiên thường được lưu ở phía server.

Token là một chuỗi dữ liệu đại diện cho thông tin xác thực hoặc quyền được cấp. Token có thể được sử dụng theo nhiều cách khác nhau, chẳng hạn access token trong hệ thống API.

Một ứng dụng có thể lưu session identifier trong cookie. Một ứng dụng khác có thể sử dụng access token, tùy vào kiến trúc và yêu cầu bảo mật.

Không nên mặc định rằng token luôn an toàn hơn session hoặc rằng sử dụng JWT sẽ tự động giải quyết mọi vấn đề xác thực. Việc lựa chọn phụ thuộc vào cách lưu trữ, thời hạn, khả năng thu hồi và cách server kiểm tra thông tin xác thực.

Đối với ứng dụng trình duyệt, lưu token trong localStorage cũng có rủi ro nếu xảy ra XSS, vì JavaScript chạy trong trang có thể đọc dữ liệu đó. Cookie HttpOnly giảm khả năng đọc cookie bằng JavaScript, nhưng ứng dụng vẫn cần cân nhắc các rủi ro như CSRF.

7. RBAC là gì?

RBAC (Role-Based Access Control) là mô hình phân quyền dựa trên vai trò. Thay vì cấp từng quyền riêng lẻ cho từng tài khoản, hệ thống nhóm quyền thành các vai trò rồi gán vai trò cho người dùng.

Ví dụ:

User
  ├── Xem hồ sơ cá nhân
  └── Chỉnh sửa hồ sơ cá nhân

Admin
  ├── Xem hồ sơ cá nhân
  ├── Quản lý người dùng
  └── Quản lý nội dung

Khi người dùng gửi yêu cầu, backend xác định vai trò và kiểm tra quyền tương ứng.

Tuy nhiên, RBAC không phải lúc nào cũng đủ. Ví dụ, hai người dùng có cùng vai trò nhưng chỉ được chỉnh sửa hồ sơ của chính mình. Khi đó, hệ thống cần kiểm tra thêm quyền sở hữu tài nguyên hoặc điều kiện cụ thể.

8. Những lỗi thường gặp khi triển khai xác thực và phân quyền

Chỉ bảo vệ giao diện: Ẩn nút quản trị không ngăn người dùng gửi yêu cầu API trực tiếp.

Tin tưởng dữ liệu do client gửi: Các giá trị như role, userId hoặc isAdmin từ trình duyệt không được xem là bằng chứng đáng tin cậy về quyền của người dùng.

Lưu thông tin nhạy cảm không an toàn: Không lưu mật khẩu hoặc secrets trong các nơi có thể bị truy cập từ client.

Không xử lý phiên hết hạn: Ứng dụng cần có cách phản hồi khi session hoặc token hết hạn, chẳng hạn yêu cầu đăng nhập lại.

Không kiểm tra quyền sở hữu tài nguyên: Việc một người dùng đã đăng nhập không đồng nghĩa họ được phép đọc hoặc sửa dữ liệu của tài khoản khác.

Không xử lý đăng xuất đúng cách: Đăng xuất cần vô hiệu hóa hoặc kết thúc trạng thái xác thực theo cơ chế được sử dụng, không chỉ điều hướng người dùng về trang đăng nhập.

9. Bài tập thực hành

Hãy xây dựng giao diện quản lý sản phẩm với hai vai trò user và admin.

1. Tạo biểu mẫu đăng nhập và gửi thông tin đến API.
2. Hiển thị trạng thái đăng nhập sau khi backend xác thực thành công.
3. Ẩn chức năng quản lý sản phẩm với người dùng không có quyền phù hợp.
4. Xử lý trường hợp session hết hạn.
5. Thử gửi trực tiếp yêu cầu đến API bằng tài khoản không đủ quyền và kiểm tra backend có từ chối hay không.
6. Xây dựng chức năng đăng xuất và kiểm tra trạng thái phiên sau khi đăng xuất.

Mục tiêu của bài tập không chỉ là làm cho giao diện hoạt động, mà còn hiểu rằng xác thực và phân quyền phải được thực hiện xuyên suốt từ frontend đến backend.

10. Kết luận

Authentication xác minh danh tính, Authorization xác định quyền truy cập, còn Session Management giúp duy trì và kết thúc trạng thái xác thực trong quá trình sử dụng ứng dụng.

Đây là những nền tảng quan trọng đối với website có tài khoản người dùng, trang quản trị hoặc dữ liệu riêng tư. Một hệ thống tốt cần kết hợp giao diện phù hợp, cơ chế xác thực đáng tin cậy, quản lý phiên an toàn và kiểm tra quyền ở phía server.

Ở bài tiếp theo, chúng ta sẽ tìm hiểu Web Security, tập trung vào XSS, CSRF và SQL Injection để nhận diện những lỗ hổng phổ biến và các biện pháp phòng tránh trong ứng dụng

web.

 

 

Bài 5: Next.js Build & Deployment – Từ mã nguồn đến môi trường Production

1. Mở đầu

Trong quá trình phát triển một ứng dụng web, việc chạy thành công trên máy tính cá nhân chưa có nghĩa là ứng dụng đã sẵn sàng để đưa đến người dùng.

Khi phát triển, chúng ta thường chạy ứng dụng bằng lệnh npm run dev. Chế độ này hỗ trợ việc lập trình và kiểm tra thay đổi nhanh chóng. Tuy nhiên, khi triển khai sản phẩm thực tế, ứng dụng cần được build, cấu hình môi trường và đưa lên một máy chủ hoặc nền tảng hosting phù hợp.

Ví dụ, một website được xây dựng bằng Next.js có thể chạy bình thường trên máy cá nhân nhưng gặp lỗi khi triển khai do thiếu biến môi trường, sai cấu hình build hoặc không tương thích với môi trường production.

Vì vậy, hiểu rõ Build và Deployment là bước quan trọng để một Frontend Developer có thể đưa ứng dụng từ mã nguồn đến môi trường sử dụng thực tế.

2. Build là gì?

Build là quá trình chuyển đổi mã nguồn thành đầu ra phù hợp để ứng dụng có thể được chạy hoặc triển khai.

Trong Next.js, quá trình build có thể bao gồm:

• Biên dịch TypeScript và JSX.
• Xử lý module và dependencies.
• Tối ưu JavaScript, CSS và tài nguyên.
• Tạo các trang HTML được render trước khi triển khai, tùy theo cấu hình và cách render.
• Chuẩn bị các thành phần cần thiết cho môi trường production.

Trong một dự án Next.js thông thường, chúng ta có thể chạy:

npm run build

Lệnh này thường thực thi script build được khai báo trong package.json, chẳng hạn:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "eslint"
  }
}

Ý nghĩa của các lệnh:

Lệnh	Mục đích
npm run dev	Chạy môi trường phát triển
npm run build	Build ứng dụng cho production
npm run start	Khởi chạy server production sau khi build, với cách triển khai Next.js phù hợp
npm run lint	Chạy ESLint nếu script được cấu hình

Lưu ý rằng npm run start không thay thế cho bước build. Với cách triển khai server Next.js thông thường, cần build thành công trước khi chạy ứng dụng ở chế độ production.

3. Phân biệt Development và Production

Development và Production là hai môi trường có mục đích khác nhau.

Development được sử dụng trong quá trình lập trình. Developer thường xuyên thay đổi mã nguồn, kiểm tra giao diện và phát hiện lỗi.

Production là môi trường phục vụ người dùng thực tế. Ứng dụng cần ổn định, có cấu hình phù hợp và được vận hành theo cách triển khai đã lựa chọn.

Một số khác biệt phổ biến:

Tiêu chí	Development	Production
Mục tiêu	Phát triển và gỡ lỗi	Phục vụ người dùng
Cách chạy	npm run dev	Build rồi triển khai theo cấu hình
Mã nguồn	Ưu tiên trải nghiệm phát triển	Được xử lý và tối ưu phù hợp
Lỗi	Có công cụ hỗ trợ debug	Cần theo dõi log và xử lý sự cố
Biến môi trường	Dùng cấu hình dành cho phát triển	Dùng cấu hình dành cho production

Không nên dùng cấu hình production tùy tiện trên máy phát triển hoặc đưa thông tin nhạy cảm của môi trường production vào mã nguồn.

4. Kiểm tra ứng dụng trước khi build

Trước khi build, Developer nên kiểm tra những yếu tố có thể gây lỗi khi triển khai.

Kiểm tra mã nguồn

Nếu dự án sử dụng TypeScript, hãy bảo đảm kiểu dữ liệu được khai báo đúng và không còn lỗi cần xử lý. Với dự án sử dụng ESLint, nên chạy kiểm tra code theo script đã cấu hình.

Ví dụ:

npm run lint
npm run build

Tùy dự án, bạn cũng có thể có các script riêng cho kiểm thử:

npm run test

Lệnh test chỉ hoạt động nếu dự án đã cấu hình công cụ kiểm thử và khai báo script tương ứng.

Kiểm tra tài nguyên

Hãy kiểm tra các đường dẫn ảnh, font, CSS và những file được import trong ứng dụng. Một đường dẫn hoạt động trên máy cá nhân không đảm bảo sẽ hoạt động khi triển khai nếu file bị thiếu hoặc cấu hình đường dẫn không đúng.

Kiểm tra các route

Đối với ứng dụng sử dụng App Router, hãy kiểm tra các trang tĩnh, dynamic routes, trang lỗi và những route cần dữ liệu từ server.

Nếu sử dụng Static Export, cần kiểm tra thêm các giới hạn của chế độ này và bảo đảm những route cần thiết đã được xuất trong quá trình build.

5. Biến môi trường trong Next.js

Trong một ứng dụng web, có những giá trị thay đổi tùy theo môi trường, chẳng hạn URL của API, thông tin kết nối dịch vụ hoặc cấu hình tích hợp.

Thay vì ghi cứng các giá trị này vào mã nguồn, Developer có thể sử dụng biến môi trường.

Ví dụ file .env.local:

API_BASE_URL=http://localhost:4000

Trong mã nguồn server:

const apiBaseUrl = process.env.API_BASE_URL;

Khi triển khai production, giá trị API_BASE_URL có thể được cấu hình thành URL API của môi trường thực tế.

Phân biệt biến môi trường phía server và phía client

Đây là một lưu ý rất quan trọng trong Next.js.

Biến môi trường không có tiền tố NEXT_PUBLIC_ thường chỉ được truy cập phía server. Biến có tiền tố NEXT_PUBLIC_ có thể được đưa vào bundle phía client và bị người dùng xem được.

Ví dụ:

NEXT_PUBLIC_API_BASE_URL=https://api.example.com
DATABASE_PASSWORD=your-secret-value

NEXT_PUBLIC_API_BASE_URL có thể được sử dụng trong code phía client nếu cần. Ngược lại, DATABASE_PASSWORD phải được giữ trong môi trường server và tuyệt đối không đưa vào client bundle.

Không nên hiểu rằng chỉ cần đặt một giá trị trong file .env là giá trị đó tự động được bảo vệ trong mọi tình huống. Vị trí sử dụng và cách build ứng dụng cũng rất quan trọng.

Đối với những giá trị NEXT_PUBLIC_ được thay thế trong mã client lúc build, thay đổi biến môi trường sau khi build không nhất thiết làm thay đổi giá trị đã được đóng gói. Điều này cần được tính đến khi thiết kế quy trình triển khai.

6. Deployment là gì?

Deployment là quá trình đưa ứng dụng đã được chuẩn bị lên môi trường để người dùng có thể truy cập.

Một quy trình deployment đơn giản có thể bao gồm:

1. Đưa mã nguồn lên Git repository.
2. Cài đặt dependencies trong môi trường build.
3. Chạy kiểm tra và build ứng dụng.
4. Cấu hình biến môi trường cần thiết.
5. Triển khai đầu ra lên nền tảng hosting phù hợp.
6. Kiểm tra ứng dụng sau khi triển khai.

Có nhiều cách triển khai Next.js, tùy vào kiến trúc của ứng dụng.

Managed hosting: Nền tảng hosting quản lý phần lớn quy trình build và triển khai. Đây là lựa chọn thuận tiện cho nhiều dự án Next.js.

Node.js server: Chạy ứng dụng Next.js trên môi trường Node.js có hỗ trợ server runtime.

Docker hoặc hạ tầng riêng: Đóng gói và vận hành ứng dụng trong môi trường do đội ngũ quản lý.

Static hosting: Phù hợp khi ứng dụng được xuất thành các tài nguyên tĩnh và không cần những chức năng phụ thuộc server runtime.

Không có một hình thức triển khai phù hợp với tất cả dự án. Cần lựa chọn dựa trên yêu cầu về dữ liệu động, xử lý server, lưu lượng truy cập và cách vận hành.

7. Quy trình triển khai Next.js với server runtime

Với một ứng dụng Next.js thông thường cần server runtime, quy trình cơ bản có thể là:

npm ci
npm run build
npm run start

Trong đó:

• npm ci cài đặt dependencies dựa trên lockfile, phù hợp với môi trường build tự động.
• npm run build tạo đầu ra production.
• npm run start khởi chạy server production theo script của dự án.

Trong môi trường triển khai thực tế, các lệnh này thường được thực hiện bởi nền tảng hosting hoặc quy trình CI/CD thay vì chạy thủ công trên máy cá nhân.

Nếu ứng dụng sử dụng tính năng cần server runtime, chỉ tải các file HTML tĩnh lên hosting có thể không đáp ứng được yêu cầu.

8. Quy trình triển khai với Static Export

Đối với dự án đã cấu hình:

const nextConfig = {
  output: "export",
};

export default nextConfig;

Sau khi chạy:

npm run build

Next.js sẽ tạo thư mục out chứa các tài nguyên tĩnh được xuất.

Khi đó, nội dung của thư mục out có thể được triển khai lên static hosting hoặc CDN phù hợp.

Cần phân biệt hai cách triển khai:

• Ứng dụng Next.js có server runtime: triển khai ứng dụng để server xử lý các tính năng cần thiết.
• Next.js Static Export: triển khai các file tĩnh đã được xuất.

Hai cách này có yêu cầu vận hành khác nhau. Không nên áp dụng cùng một quy trình mà không kiểm tra khả năng hỗ trợ của nền tảng đích.

9. CI/CD và tự động hóa deployment

Khi làm việc nhóm, việc build và triển khai thủ công sau mỗi thay đổi có thể mất thời gian và dễ phát sinh sai sót.

CI/CD là nhóm thực hành và quy trình giúp tự động hóa các bước như kiểm tra code, chạy test, build và triển khai ứng dụng.

Continuous Integration (CI) tập trung vào việc tích hợp thay đổi thường xuyên và kiểm tra chúng thông qua các quy trình tự động.

Continuous Delivery hoặc Continuous Deployment (CD) giúp tự động hóa việc chuẩn bị bản phát hành hoặc triển khai sản phẩm, tùy theo quy trình của đội ngũ.

Ví dụ, một quy trình có thể được thiết kế như sau:

Developer push code
        ↓
CI chạy lint và test
        ↓
Build ứng dụng
        ↓
Build thành công?
   ↙            ↘
 Không           Có
  ↓               ↓
Báo lỗi       Deploy
                  ↓
           Kiểm tra ứng dụng

Khi triển khai CI/CD, cần bảo vệ secrets trong hệ thống quản lý biến môi trường của nền tảng tự động hóa, giới hạn quyền truy cập và không ghi các thông tin nhạy cảm vào log.

10. Kiểm tra sau khi deployment

Build thành công không có nghĩa là ứng dụng chắc chắn hoạt động đúng sau khi triển khai. Một số lỗi chỉ xuất hiện khi chạy trên môi trường production.

Sau deployment, nên kiểm tra:

• Trang chủ và các route quan trọng có truy cập được không.
• Hình ảnh, font và CSS có tải thành công không.
• Các yêu cầu API có sử dụng đúng URL không.
• Những chức năng cần xác thực có hoạt động đúng không.
• Các biến môi trường có được cấu hình đầy đủ không.
• Trang lỗi và trạng thái loading có hiển thị phù hợp không.
• Log và hệ thống theo dõi có phát hiện lỗi runtime hay không.

Nếu ứng dụng sử dụng domain riêng, hãy kiểm tra thêm HTTPS, DNS và cấu hình domain của nền tảng hosting.

Đối với dự án quan trọng, có thể sử dụng staging environment để kiểm tra bản phát hành trước khi đưa vào production.

11. Những lỗi thường gặp khi triển khai

Thiếu biến môi trường: Ứng dụng có thể build thất bại hoặc gọi sai API do thiếu cấu hình.

Đưa secrets vào frontend: Các khóa bí mật có thể bị lộ nếu được đưa vào client bundle.

Chọn sai hình thức hosting: Static hosting không thể thay thế server runtime cho các chức năng cần xử lý request động.

Chỉ kiểm tra trên development: Một số lỗi chỉ xuất hiện trong bản production hoặc trên môi trường thực tế.

Không kiểm tra sau deployment: Ứng dụng có thể triển khai thành công nhưng vẫn lỗi khi người dùng truy cập một route cụ thể.

Không có phương án rollback: Khi bản phát hành mới gặp sự cố, việc không thể quay về bản ổn định có thể làm tăng thời gian gián đoạn dịch vụ.

12. Bài tập thực hành

Hãy xây dựng một dự án Next.js đơn giản và chuẩn bị triển khai production.

1. Kiểm tra các script trong package.json.
2. Chạy lint và các bài test đã cấu hình.
3. Tạo biến môi trường dành cho URL API.
4. Chạy npm run build.
5. Chạy thử ứng dụng production cục bộ nếu sử dụng server runtime.
6. Triển khai lên nền tảng hosting phù hợp.
7. Kiểm tra các route, tài nguyên và yêu cầu API.
8. Ghi lại những lỗi phát sinh và cách khắc phục.

Nếu dự án sử dụng Static Export, hãy thực hiện thêm bước kiểm tra thư mục out và triển khai các tài nguyên tĩnh thay vì chạy server Next.js.

13. Kết luận

Build và Deployment là hai bước quan trọng trong quá trình đưa ứng dụng Next.js từ môi trường phát triển đến người dùng thực tế. Build chuẩn bị đầu ra production, còn deployment đưa đầu ra đó lên môi trường vận hành phù hợp.

Một quy trình tốt không chỉ dừng lại ở việc chạy thành công lệnh build. Developer còn cần quản lý biến môi trường, lựa chọn hình thức hosting, kiểm tra sau deployment và xây dựng quy trình tự động hóa khi dự án phát triển.

Khi hiểu rõ những bước này, Frontend Developer có thể chủ động hơn trong việc phát hành ứng dụng, phối hợp với Backend và DevOps, cũng như xử lý các vấn đề thường gặp trong môi trường production.

Bài viết này hoàn thành nhóm chủ đề Next.js Advanced & Production của Series 6, bao gồm Metadata & SEO, Internationalization & Localization, Internationalized Routing, Static Export và Build & Deployment.