Tweet
Tối ưu hóa việc sử dụng API
API được thiết kế để sử dụng nhiều. Nó được dùng từ nhiều ứng dụng khách khác nhau. Ngoài ra, nó còn được sử dụng nhiều lần từ cùng một ứng dụng khách, thậm chí trong cùng một phiên. Vì vậy, khi biết rằng một thứ sẽ được sử dụng nhiều, bạn cần tối ưu hóa. Bạn muốn tối ưu hóa thời gian. Bạn muốn tối ưu hóa tài nguyên.
Vì thế, bạn cần nghĩ xem có thể làm gì để có trải nghiệm tốt hơn và tiết kiệm tài nguyên. Một số lý do khiến bạn muốn tối ưu hóa, lý do đầu tiên là thời gian phản hồi. Nếu bạn không cần thực hiện công việc đó, nó sẽ nhanh hơn. Nếu bạn không cần gửi dữ liệu, bạn đang tiết kiệm băng thông. Và điều này cũng sẽ nhanh hơn.
Nếu bạn không cần xử lý gì đó, một lần nữa, nó sẽ nhanh hơn. Nó sẽ tốn ít công sức hơn. Bằng cách làm ít công việc hơn, bạn tiết kiệm được rất nhiều thời gian. Bạn tiết kiệm được rất nhiều tài nguyên, mà sau đó có thể được sử dụng bởi nhiều người dùng khác trên nền tảng. Vì vậy, việc tối ưu hóa này thực sự rất quan trọng.
Làm thế nào để bạn, với tư cách là một nhà phát triển, tối ưu hóa các lệnh gọi API? Cách đầu tiên, thực sự rất dễ, là phân trang (pagination), tức là bạn chỉ yêu cầu lượng dữ liệu mà bạn có thể xử lý và thực sự sẽ sử dụng. Nếu bạn không định đọc hết dữ liệu, bạn có thể chỉ yêu cầu đủ dữ liệu cho, ví dụ, một hoặc hai trang trên màn hình của người dùng cuối.
Bằng cách này, bạn giảm tải công việc cho máy chủ, truyền ít dữ liệu hơn qua mạng, sử dụng ít băng thông hơn, và đồng thời tiết kiệm dung lượng CPU và bộ nhớ trên thiết bị của người dùng cuối. Tiếp theo là nén dữ liệu (compression). Nén dữ liệu thường có nghĩa là ít dữ liệu cần đọc, ít dữ liệu cần xử lý, ít dữ liệu cần truyền.
Việc nén dữ liệu có thể giúp rất nhiều, nhưng đổi lại sẽ tiêu tốn thêm tài nguyên xử lý CPU. Tuy nhiên, một số vấn đề này có thể được giảm thiểu. Ví dụ, nếu bạn nén trước dữ liệu trên máy chủ ở phía xa, bạn chỉ cần dành thời gian để nén dữ liệu. Bằng cách nén trước dữ liệu trên máy chủ, máy chủ sẽ cần đọc ít dữ liệu hơn và không phải thực hiện nén tự động.
Phần cuối cùng là lưu trữ đệm (caching). Nếu dữ liệu không thay đổi nhiều, bạn có thể thực hiện lưu trữ đệm ở cấp độ ứng dụng khách, ở cấp độ trung gian, và ở cấp độ máy chủ từ xa. Bộ đệm đầu tiên mà bạn thường có thể sử dụng là bộ đệm ứng dụng khách.
Nếu ứng dụng khách giữ một bản sao cục bộ của dữ liệu đã được lưu trữ trước đó, khi nó kết nối với máy chủ từ xa, nó có thể yêu cầu: "Cho tôi cùng một trang, nhưng chỉ nếu trang đó đã thay đổi sau thời điểm bản sao cục bộ của tôi." Đây là một yêu cầu có điều kiện (conditional get). Đó là một cách để thực hiện lưu trữ đệm.
Ví dụ, bạn có thể đặt một proxy lưu trữ đệm trước máy chủ từ xa, proxy này sẽ theo dõi lưu lượng đi qua và có thể lưu trữ tất cả dữ liệu đã được gửi qua nó. Lần tiếp theo khi ứng dụng khách yêu cầu một thứ gì đó, proxy có thể trả lời: "Đây, bạn lấy nó." Và nó thậm chí không cần liên hệ với máy chủ backend. Hoặc có thể nó chỉ liên hệ với máy chủ backend để xác nhận rằng bản sao lưu trữ trên proxy vẫn còn mới.
Bằng cách này, bạn vẫn tiết kiệm được tài nguyên. Bạn vẫn tiết kiệm được thời gian. Và khi có, giả sử, hàng nghìn người dùng cùng truy cập vào cùng một tệp lặp đi lặp lại trong 5 giây, 10 giây, bạn thực sự có thể tiết kiệm được rất nhiều tài nguyên. Bạn có thể tiết kiệm rất nhiều thời gian trong việc xử lý các yêu cầu đó.