Lọc phía máy chủ vs phía trình duyệt: danh sách kiểm tra để quyết định

Vấn đề thực sự: rò rỉ, chậm và kết quả không nhất quán

Lọc trong UI không chỉ là một ô tìm kiếm. Nó thường gồm vài hành động liên quan thay đổi những gì người dùng thấy: tìm theo chữ (tên, email, mã đơn), các facet (trạng thái, người sở hữu, khoảng ngày, thẻ), và sắp xếp (mới nhất, giá trị cao nhất, hoạt động cuối cùng).

Câu hỏi then chốt không phải kỹ thuật nào “tốt hơn”. Mà là nơi lưu dataset đầy đủ, và ai được phép truy cập nó. Nếu trình duyệt nhận các bản ghi mà người dùng không nên thấy, UI có thể phơi bày dữ liệu nhạy cảm ngay cả khi bạn ẩn nó về mặt hiển thị.

Hầu hết tranh luận về server-side vs client-side filtering thực ra là phản ứng trước hai thất bại người dùng nhận thấy ngay:

• Rò rỉ: dữ liệu xuất hiện trong payload mạng, phản hồi được cache, hoặc qua các bộ lọc bất ngờ làm lộ hàng ẩn.
• Chậm: màn hình cảm thấy ì vì bạn gửi quá nhiều dữ liệu, rồi bắt thiết bị làm việc nặng mỗi khi gõ.

Có một vấn đề thứ ba gây báo lỗi bất tận: kết quả không nhất quán. Nếu một số bộ lọc chạy trên client và số khác chạy trên server, người dùng sẽ thấy tổng, trang và số lượng không khớp. Điều đó làm mất niềm tin rất nhanh, đặc biệt trên danh sách phân trang.

Một mặc định thực tế là đơn giản: nếu người dùng không được phép truy cập toàn bộ dataset, thì lọc trên server. Nếu được phép và dataset đủ nhỏ để tải nhanh, lọc trên client có thể chấp nhận được.

Định nghĩa nhanh bằng ngôn ngữ thông thường

Lọc chỉ là “hiển thị các mục khớp”. Câu hỏi là việc khớp xảy ra ở đâu: trên trình duyệt của người dùng (client) hay trên backend của bạn (server).

Lọc phía client chạy trong trình duyệt. Ứng dụng tải một tập bản ghi (thường JSON), rồi áp bộ lọc cục bộ. Sau khi dữ liệu đã tải, nó có thể cảm thấy tức thì, nhưng chỉ hoạt động khi dataset đủ nhỏ để gửi và đủ an toàn để phơi bày.

Lọc phía server chạy trên backend. Trình duyệt gửi các input lọc (ví dụ status=open, owner=me, createdAfter=Jan 1), và server trả về chỉ kết quả khớp. Thực tế, đây thường là một endpoint API nhận filter, dựng truy vấn cơ sở dữ liệu, và trả về danh sách phân trang cùng tổng số.

Mô hình tư duy đơn giản:

• Client-side: tải nhiều, lọc ở đây.
• Server-side: yêu cầu chính xác những gì cần.

Các setup kết hợp là phổ biến. Một mô hình tốt là thực thi các bộ lọc “lớn” trên server (quyền, sở hữu, khoảng ngày, tìm kiếm), rồi dùng các toggle nhỏ chỉ cho UI cục bộ (ẩn mục lưu trữ, chip thẻ nhanh, hiển thị cột) mà không cần request thêm.

Sắp xếp, phân trang và tìm kiếm thường thuộc cùng quyết định. Chúng ảnh hưởng đến kích thước payload, cảm nhận người dùng và dữ liệu bạn đang phơi bày.

Yếu tố quyết định 1: kích thước dữ liệu và chi phí payload

Bắt đầu bằng câu hỏi thực tế nhất: bạn sẽ gửi bao nhiêu dữ liệu tới trình duyệt nếu lọc trên client? Nếu câu trả lời trung thực là “nhiều hơn vài màn hình”, bạn sẽ trả giá bằng thời gian tải, bộ nhớ và các tương tác chậm.

Bạn không cần ước lượng hoàn hảo. Chỉ cần biết bậc: người dùng có thể thấy bao nhiêu hàng, và kích thước trung bình mỗi hàng ra sao? Danh sách 500 mục với vài trường ngắn rất khác so với 50.000 mục mà mỗi hàng chứa ghi chú dài, rich text hoặc object lồng.

Bản ghi rộng là kẻ giết payload thầm lặng. Một bảng có thể trông nhỏ về số hàng nhưng nặng nếu mỗi hàng chứa nhiều trường, chuỗi lớn, hoặc dữ liệu join (contact + công ty + hoạt động cuối + địa chỉ đầy đủ + thẻ). Dù chỉ hiển thị ba cột, các team thường gửi “mọi thứ, phòng khi cần”, và payload phình ra.

Cũng nghĩ đến tăng trưởng. Dataset hôm nay ổn có thể trở nên nặng chỉ sau vài tháng. Nếu dữ liệu tăng nhanh, coi lọc phía client là giải pháp tạm thời, không phải mặc định.

Quy tắc tham khảo:

• Nếu bạn không thể gửi toàn bộ dataset thoải mái qua kết nối di động điển hình, hãy lọc trên server.
• Nếu người dùng chỉ thao tác một lát cắt nhỏ tại một thời điểm, lấy lát cắt đó và lọc ở server.
• Nếu dataset nhỏ, ổn định và thực sự an toàn để phơi bày, lọc phía client có thể cho trải nghiệm tốt.

Điểm cuối cùng không chỉ về hiệu năng. “Chúng ta có thể gửi toàn bộ dataset lên trình duyệt không?” cũng là câu hỏi bảo mật. Nếu không thể trả lời chắc chắn là có, thì đừng gửi.

Yếu tố quyết định 2: độ trễ và cảm nhận người dùng

Quyết định lọc thường thất bại về cảm nhận, không phải về tính đúng. Người dùng không đo mili giây. Họ nhận thấy giật, nhấp nháy và kết quả nhảy lung tung khi họ gõ.

Thời gian có thể mất ở nhiều chỗ khác nhau:

• Mạng: thời gian request/response và kích thước payload
• Server: truy vấn cơ sở dữ liệu, join, sắp xếp, kiểm tra quyền
• Trình duyệt: parse JSON, render hàng, lọc mảng lớn

Xác định “nhanh đủ” cho màn hình này. Một view danh sách có thể cần phản hồi khi gõ và cuộn mượt, trong khi một trang báo cáo có thể chịu đựng chờ hơi lâu miễn là kết quả đầu tiên xuất hiện nhanh.

Đừng chỉ đánh giá trên Wi‑Fi văn phòng. Trên kết nối chậm, lọc phía client có thể cho cảm nhận tốt sau lần tải đầu, nhưng lần tải đầu có thể rất chậm. Lọc phía server giữ payload nhỏ, nhưng có thể cảm thấy trễ nếu bạn gửi request cho mỗi phím bấm.

Thiết kế xoay quanh input của con người. Debounce request khi gõ. Với tập kết quả lớn, dùng tải dần để trang hiển thị thứ gì đó nhanh và giữ mượt khi người dùng cuộn.

Yếu tố quyết định 3: quyền truy cập và phơi bày dữ liệu

Quyền truy cập nên quyết định cách lọc hơn là chỉ tốc độ. Nếu trình duyệt từng nhận dữ liệu mà người dùng không được xem, bạn đã có vấn đề, ngay cả khi bạn ẩn nó phía UI.

Bắt đầu bằng cách liệt kê trường nào nhạy cảm trên màn hình này. Một số trường rõ ràng (email, số điện thoại, địa chỉ). Những trường khác dễ bị bỏ sót: ghi chú nội bộ, chi phí hoặc biên lợi nhuận, quy tắc giá đặc biệt, điểm rủi ro, cờ kiểm duyệt.

Cái bẫy lớn là “chúng ta lọc ở client, nhưng chỉ hiển thị hàng được phép”. Điều đó vẫn nghĩa là dataset đầy đủ đã được tải. Bất kỳ ai cũng có thể kiểm tra phản hồi mạng, mở dev tools hoặc lưu payload. Ẩn cột trong UI không phải là kiểm soát truy cập.

Khi nào server-side là mặc định an toàn

Lọc phía server là mặc định an toàn khi ủy quyền khác nhau theo user, đặc biệt khi người dùng khác nhau có thể thấy các hàng khác nhau hoặc các trường khác nhau.

Kiểm tra nhanh:

• Có vai trò khác nhau thấy các hàng khác nhau không (chỉ team, chỉ vùng, chỉ người được gán)?
• Có vai trò thấy các trường khác nhau không (ghi chú, giá, PII)?
• Có quy tắc cấp hàng (chủ tài khoản, giai đoạn giao dịch, cờ “riêng tư”)?
• Xuất dữ liệu, sắp xếp hoặc tổng số có thể tiết lộ thông tin bị hạn chế không?
• Một payload bị rò rỉ có thể gây ra vấn đề tuân thủ không?

Nếu có bất kỳ câu trả lời nào là có, giữ việc lọc và lựa chọn trường ở server. Chỉ gửi những gì người dùng được phép thấy, và áp cùng quy tắc cho tìm kiếm, sắp xếp, phân trang và xuất.

Ví dụ: trong danh sách contact của CRM, đại diện bán hàng chỉ xem account của họ trong khi quản lý xem toàn bộ. Nếu trình duyệt tải về tất cả contact rồi lọc cục bộ, đại diện vẫn có thể phục hồi account ẩn từ phản hồi. Lọc phía server ngăn điều đó bằng cách không bao giờ gửi các hàng đó.

Yếu tố quyết định 4: cache và tính mới

Caching có thể làm màn hình cảm thấy tức thì. Nó cũng có thể hiển thị thông tin sai. Chìa khóa là quyết định bạn được phép tái sử dụng gì, trong bao lâu, và sự kiện nào phải xóa cache.

Bắt đầu bằng cách chọn đơn vị cache. Cache toàn bộ danh sách đơn giản nhưng thường lãng phí băng thông và nhanh lỗi thời. Cache theo trang phù hợp với infinite scroll. Cache theo truy vấn (filter + sắp xếp + tìm kiếm) chính xác, nhưng có thể phình nhanh nếu người dùng thử nhiều tổ hợp.

Tính mới quan trọng hơn trong một số miền. Nếu dữ liệu thay đổi nhanh (tồn kho, số dư, trạng thái giao hàng), ngay cả cache 30 giây cũng có thể làm người dùng hiểu nhầm. Nếu dữ liệu thay đổi chậm (bản ghi lưu trữ, dữ liệu tham chiếu), cache lâu hơn thường ổn.

Lên kế hoạch invalidation trước khi code. Ngoài thời gian trôi qua, quyết định hành động nào phải ép refresh: tạo/sửa/xóa, thay đổi quyền, import/merge hàng loạt, chuyển trạng thái, undo/rollback, và các job nền cập nhật trường mà người dùng lọc.

Cũng chọn nơi cache nằm. Bộ nhớ trình duyệt giúp back/forward nhanh, nhưng có thể rò rỉ dữ liệu giữa các tài khoản nếu bạn không khóa theo user và org. Cache phía backend an toàn hơn cho quyền và nhất quán, nhưng phải bao gồm đầy đủ chữ ký filter và danh tính caller để kết quả không bị lẫn.

Bước theo bước: cách chọn cho một màn hình mới

Mục tiêu không thể thương lượng: màn hình phải cảm giác nhanh mà không rò rỉ dữ liệu.

Luồng quyết định thực tế

1. Bắt đầu với ràng buộc mạnh nhất. Nếu truy cập thay đổi theo vai trò, team, vùng, org, hoặc gói, quyền thắng. Nếu dataset lớn hoặc có thể tăng nhanh, kích thước thắng.
2. Mặc định dùng server-side khi dữ liệu lớn hoặc nhạy cảm. Nếu bạn không thoải mái log toàn bộ dataset trong console trình duyệt, đừng gửi.
3. Dùng client-side chỉ cho danh sách nhỏ, an toàn và tái sử dụng. Dropdown trạng thái, danh sách thẻ nhỏ, một trang kết quả đã được duyệt.
4. Định nghĩa API trước UI. Ghi rõ filters, sắp xếp, phân trang và mặc định để server và UI không tranh nhau.
5. Thêm rào chắn. Thiết lập max page size, timeouts, và quy định UI khi lọc chậm (hiện spinner, giữ kết quả cũ, hoặc gợi ý thử lại).

Sai lầm phổ biến gây rò rỉ hoặc chậm

Phần lớn team bị vấp cùng kiểu: UI đẹp trong demo, rồi dữ liệu thật, quyền thật và tốc độ mạng thật lộ ra các vết nứt.

Sai lầm làm rò rỉ dữ liệu

Thất bại nghiêm trọng nhất là coi lọc chỉ là trình bày. Nếu trình duyệt nhận bản ghi không nên có, bạn đã mất.

Hai nguyên nhân thường gặp:

• Gửi toàn bộ dataset tới trình duyệt và lọc cục bộ “để nhanh”. Bất kỳ ai cũng có thể kiểm tra phản hồi hoặc truy vấn nó trong bộ nhớ.
• Cache phản hồi đã lọc mà không gắn khóa cache với danh tính user, org, role, hoặc phiên bản chính sách. Thay đổi quyền có thể âm thầm làm lộ dữ liệu cũ.

Ví dụ: thực tập sinh chỉ nên thấy leads vùng họ phụ trách. Nếu API trả về tất cả vùng và dropdown lọc bằng React, thực tập sinh vẫn có thể trích xuất toàn bộ danh sách.

Sai lầm làm màn hình cảm thấy chậm

Độ trễ thường đến từ giả định:

• Cho rằng lọc client luôn nhanh hơn. Với 50.000 hàng, tải và parse có thể lâu hơn một truy vấn tập trung.
• Quên phân trang và trạng thái tải. Màn hình chặn trong khi render danh sách khổng lồ cảm thấy như hỏng dù truy vấn đúng.

Một vấn đề tinh tế nhưng đau là quy tắc không khớp. Nếu server xử lý “starts with” khác client, người dùng thấy tổng không khớp, hoặc mục biến mất sau khi refresh.

Danh sách kiểm tra nhanh trước khi phát hành

Làm bước rà soát cuối với hai tư duy: người dùng tò mò và ngày mạng tệ.

• Payload hợp lý: xác nhận phản hồi không bao giờ chứa hàng hoặc trường người dùng không nên thấy, ngay cả khi UI ẩn chúng. Chú ý tổng số, nhóm đếm, hoặc ID có thể khiến ai đó suy ra dữ liệu bị hạn chế.
• Ghi log an toàn: các filter thường chứa email, tên hoặc ID. Đừng ghi lại giá trị filter nhạy cảm, SQL đầy đủ, hoặc body request đầy đủ ở nơi nhiều người truy cập.
• Nhất quán giữa thiết bị: áp cùng bộ lọc trên desktop và mobile. Khác biệt thường từ sắp xếp client-side, quy tắc locale (chữ hoa, dấu) hoặc giá trị mặc định.
• Trạng thái rõ ràng: loading, empty và error phải rõ. Test thay đổi nhanh (gõ, xóa, toggle) để UI không nhấp nháy hoặc hiện kết quả cũ.
• Rào chắn trường hợp xấu nhất: max page size, max date range và timeouts. Bảo vệ khỏi truy vấn đắt đỏ (wildcard, quá nhiều OR, trường không được lập chỉ mục).

Một bài test đơn giản: tạo một bản ghi bị hạn chế và xác nhận nó không bao giờ xuất hiện trong payload, tổng số, hoặc cache, ngay cả khi bạn lọc rộng hoặc xóa bộ lọc.

Ví dụ tình huống: danh sách contact trong CRM

Hình dung một CRM với 200.000 contact. Đại diện bán hàng chỉ thấy account của họ, quản lý thấy team họ, admin thấy mọi thứ. Màn hình có tìm kiếm, bộ lọc (trạng thái, owner, hoạt động gần nhất) và sắp xếp.

Lọc phía client thất bại nhanh ở đây. Payload nặng, lần tải đầu chậm, và rủi ro rò rỉ dữ liệu cao. Dù UI ẩn hàng, trình duyệt vẫn nhận dữ liệu. Bạn cũng đẩy áp lực lên thiết bị: mảng lớn, sắp xếp nặng, chạy bộ lọc nhiều lần, dùng nhiều nhớ và crash trên điện thoại cũ.

Cách an toàn hơn là lọc phía server với phân trang. Client gửi lựa chọn filter và text tìm kiếm, server trả về chỉ các hàng người dùng được phép thấy, đã lọc và sắp xếp.

Mẫu thực tế:

• Áp quyền trước, rồi đến filter và sort.
• Trả về một trang mỗi lần (ví dụ 50 hàng) kèm tổng số.
• Cache cẩn trọng (theo user hoặc theo role) để không trộn kết quả giữa các quyền.

Ngoại lệ nhỏ khi client-side ổn: dữ liệu tiny, tĩnh. Dropdown “Contact status” với 8 giá trị có thể tải một lần và lọc cục bộ mà ít rủi ro hoặc chi phí.

Bước tiếp theo: ghi lại quyết định và xây dựng ít phải viết lại hơn

Các team thường không bị cháy vì chọn sai một lần. Họ bị cháy vì chọn khác nhau cho mỗi màn hình, rồi cố sửa rò rỉ và trang chậm khi đang chịu áp lực.

Viết một ghi chú quyết định ngắn cho mỗi màn hình gồm: kích thước dataset, chi phí gửi, cảm nhận "nhanh đủ" là gì, trường nào nhạy cảm, và cách cache (hoặc không). Giữ server và UI đồng bộ để không có “hai chân lý” cho việc lọc.

Nếu bạn đang xây nhanh bằng Koder.ai (koder.ai), nên quyết trước bộ lọc nào phải thực thi trên backend (quyền và truy cập hàng) và toggle UI nhỏ nào có thể ở lớp React. Một lựa chọn như vậy tránh được những lần viết lại tốn kém sau này.