Tweet
Senior DevOps:
"REST API là một phương pháp cực kỳ mạnh để trao đổi dữ liệu, đúng không? Và nhờ đó, em có thể lấy về một lượng kết quả rất lớn từ một truy vấn—ví dụ như khi em tìm kiếm thông tin thiết bị hoặc người dùng từ một hệ thống lớn. Nhưng vấn đề là: làm sao để xử lý lượng dữ liệu lớn đó mà không khiến user chờ đợi lâu hay tốn tài nguyên quá mức?"
"Chìa khóa nằm ở chỗ: mình phải tối ưu cả phía server lẫn phía client. Có nhiều cách để làm điều đó, như là caching, phân trang, hoặc giới hạn dữ liệu trả về. Và đặc biệt, em luôn phải chuẩn bị tinh thần cho việc nhận về những tập dữ liệu rất lớn – không được assume là API sẽ trả về 5-10 dòng đâu nhé."
Junior DevOps:
"Dạ, vậy mình nên làm gì để giới hạn hoặc chia nhỏ kết quả?"
Senior DevOps:
"Hay, đó là lúc mình dùng đến offset và limit – giống như khi truy vấn database vậy.
Ví dụ, offset=20&limit=10 nghĩa là em bắt đầu lấy từ bản ghi thứ 20 và chỉ lấy 10 bản ghi. Cách này giúp em không chỉ kiểm soát được lượng dữ liệu, mà còn tiết kiệm rất nhiều tài nguyên xử lý, cả ở phía backend lẫn thiết bị người dùng."
"Em thử tưởng tượng: nếu không giới hạn, server sẽ phải xử lý toàn bộ dữ liệu, gửi hết về client – điều này gây nghẽn mạng, tăng độ trễ, thậm chí làm treo trình duyệt hay app mobile nếu thiết bị yếu. Đó là lý do tại sao các API backend thường được thiết kế có phân trang sẵn."
Junior DevOps:
"Em thấy nhiều API còn trả về cả metadata nữa, mấy cái đó dùng để làm gì ạ?"
Senior DevOps:
"Đúng rồi! Metadata trong response cực kỳ quan trọng. Nó có thể cho em biết:
- Trang hiện tại đang là bao nhiêu
- Có bao nhiêu kết quả tổng cộng
- Mỗi trang có bao nhiêu bản ghi
- Và thậm chí là có bao nhiêu trang tất cả
Thường em còn sẽ thấy một thứ gọi là ETag nữa. Nó là một định danh cho phiên bản của dữ liệu. Nếu dữ liệu thay đổi, ETag cũng thay đổi theo. Điều này giúp em tận dụng được cache – ví dụ: trình duyệt hoặc proxy có thể kiểm tra xem dữ liệu mới chưa, nếu chưa thì dùng lại bản cũ, tiết kiệm băng thông."
Junior DevOps:
"Vậy lúc người dùng muốn xem trang kế tiếp thì sao ạ?"
Senior DevOps:
"Hay, lúc đó là lúc navigational links phát huy tác dụng. Server nên trả về các link điều hướng như:
- next
- previous
- first
- last
Như vậy, client không cần biết quá nhiều logic, chỉ cần dựa theo các link đó để gọi tiếp dữ liệu. Nó cũng giúp client code gọn hơn, dễ maintain hơn."
Junior DevOps:
"Vậy nếu app chỉ có vài user thì mình có cần lo chuyện tối ưu này không?"
Senior DevOps:
"Đừng chủ quan nha. Em phải luôn thiết kế cho quy mô lớn, ngay cả khi hệ thống hiện tại chỉ có vài chục người dùng. Tưởng tượng khi app của em thành công, người ta dùng nó trên điện thoại, mạng chậm, dung lượng data hạn chế. Mình mà gửi cả ngàn dòng dữ liệu chỉ để hiển thị vài dòng đầu, thì vừa tốn data, vừa chậm, lại ảnh hưởng UX."
"Chưa kể, mobile device có màn hình nhỏ, RAM yếu, CPU giới hạn, nên việc xử lý dữ liệu cũng nên càng nhẹ nhàng càng tốt. Tối ưu response size còn giúp server trả lời nhanh hơn, client render mượt hơn, mọi thứ đều lợi."
Junior DevOps:
"Dạ hiểu rồi anh! Cảm ơn anh nhiều!"
Senior DevOps:
"Good. Nhớ nha – REST API mà không phân trang, không limit dữ liệu, là như nấu ăn không có muối – có thể sống được, nhưng không ngon và khó nuốt!"