Validation là phần tưởng nhỏ nhưng ảnh hưởng trực tiếp đến trải nghiệm người dùng, chất lượng dữ liệu và cả bảo mật hệ thống. Một form đăng ký, màn hình tạo đơn hàng hay API cập nhật hồ sơ đều cần trả lời câu hỏi: dữ liệu này có hợp lệ không, và nếu không thì báo cho ai, báo như thế nào? Sai lầm phổ biến là chỉ validation ở frontend vì “người dùng nhìn thấy ngay”. Frontend validation rất hữu ích cho trải nghiệm, nhưng không đủ an toàn. Người dùng có thể tắt JavaScript, sửa request bằng công cụ devtools, gọi thẳng API hoặc dùng client cũ. Vì vậy, nguyên tắc thực tế là: frontend giúp người dùng nhập đúng, backend quyết định dữ liệu có được chấp nhận hay không. Một số lớp validation nên có: - Frontend: kiểm tra nhanh các lỗi dễ thấy như bắt buộc nhập, định dạng email, độ dài mật khẩu, số lượng sản phẩm không âm. Mục tiêu là phản hồi tức thì và giảm thao tác thừa. - Backend/API: kiểm tra lại toàn bộ quy tắc quan trọng. Đây là lớp bắt buộc vì backend là nơi bảo vệ dữ liệu thật. - Database: dùng constraint khi phù hợp, ví dụ NOT NULL, UNIQUE, foreign key, check constraint. Đây là “lưới an toàn” cuối cùng để tránh dữ liệu bẩn lọt vào. Ví dụ thực tế: một màn hình cập nhật số điện thoại. Frontend có thể chặn ký tự không phải số và báo “Số điện thoại cần từ 10 đến 11 chữ số”. Backend vẫn phải kiểm tra lại, chuẩn hóa dữ liệu nếu cần, và trả lỗi có cấu trúc như field: phone, message: Số điện thoại không hợp lệ. Database có thể đặt unique nếu mỗi số điện thoại chỉ được gắn với một tài khoản. Khi thiết kế validation, nên phân biệt rõ ba loại lỗi: - Lỗi định dạng: email sai, ngày tháng không hợp lệ, chuỗi quá dài. - Lỗi nghiệp vụ: không thể đặt số lượng vượt tồn kho, không được rút tiền lớn hơn số dư. - Lỗi trạng thái: đơn hàng đã hủy nên không thể cập nhật địa chỉ giao hàng. Cách trả lỗi cũng rất quan trọng. Thay vì chỉ trả “Bad request”, hãy trả thông tin đủ để client hiển thị đúng chỗ. Với form nhiều trường, người dùng cần biết trường nào sai. Với lỗi nghiệp vụ, thông báo nên nói rõ hành động tiếp theo: “Sản phẩm chỉ còn 2 cái, vui lòng giảm số lượng” tốt hơn “Dữ liệu không hợp lệ”. Một lời khuyên có thể áp dụng ngay: hãy định nghĩa validation gần với model hoặc schema dùng chung trong backend, tránh rải quy tắc ở quá nhiều nơi. Nếu frontend và backend dùng chung được schema thì càng tốt, nhưng đừng đánh đổi bằng việc làm lộ logic nhạy cảm hoặc khiến client phụ thuộc quá chặt vào backend. Ngoài ra, cần chú ý đến dữ liệu sau khi validation. Đừng chỉ kiểm tra hợp lệ, hãy chuẩn hóa trước khi lưu: trim khoảng trắng, chuyển email về chữ thường nếu chính sách hệ thống cho phép, chuẩn hóa mã quốc gia, ép kiểu rõ ràng cho số và ngày tháng. Nhiều lỗi khó chịu đến từ dữ liệu “trông giống nhau” nhưng thực ra khác nhau, như email có khoảng trắng cuối chuỗi. Tóm lại, validation tốt không phải là viết thật nhiều điều kiện if. Đó là thiết kế một quy trình rõ ràng: giúp người dùng nhập đúng ở frontend, bảo vệ hệ thống ở backend, dùng database làm lớp chặn cuối, và trả lỗi đủ rõ để người dùng sửa được. Làm tốt phần này sẽ giúp ứng dụng ổn định hơn, dữ liệu sạch hơn và giảm đáng kể thời gian xử lý lỗi về sau.