Bạn gặp khó khăn khi cố gắng bảo vệ độ tin cậy của mạng. Bộ nhớ đệm HTTP của trình duyệt là tuyến phòng vệ đầu tiên, nhưng như bạn đã tìm hiểu, bộ nhớ đệm này chỉ thực sự hiệu quả khi tải các URL có phiên bản mà bạn đã truy cập trước đó. Bản thân bộ nhớ đệm HTTP là chưa đủ.
May mắn thay, chúng tôi đã ra mắt 2 công cụ mới hơn: service worker và Cache Storage API. Vì chúng thường được sử dụng cùng nhau, nên bạn nên tìm hiểu về cả hai cùng một lúc.
Trình chạy dịch vụ
Trình chạy dịch vụ được tích hợp vào trình duyệt và được điều khiển bằng một số mã JavaScript bổ sung mà bạn chịu trách nhiệm tạo. Bạn triển khai tệp này cùng với các tệp khác tạo nên ứng dụng web thực tế của mình.
Nhân viên dịch vụ có một số quyền hạn đặc biệt. Cùng với nhiều nhiệm vụ khác, lớp này sẽ kiên nhẫn chờ ứng dụng web của bạn đưa ra một yêu cầu đi, sau đó khởi động bằng cách chặn yêu cầu đó. Bạn sẽ quyết định việc mà trình chạy dịch vụ thực hiện với yêu cầu bị chặn này.
Đối với một số yêu cầu, phương án hành động tốt nhất có thể là chỉ cho phép yêu cầu tiếp tục kết nối với mạng, giống như điều sẽ xảy ra nếu không có trình chạy dịch vụ nào.
Tuy nhiên, đối với các yêu cầu khác, bạn có thể tận dụng một tính năng linh hoạt hơn bộ nhớ đệm HTTP của trình duyệt và trả về phản hồi nhanh đáng tin cậy mà không phải lo lắng về mạng. Để làm được điều này, bạn cần sử dụng một giải pháp khác: API Bộ nhớ đệm.
API Bộ nhớ đệm
API Bộ nhớ đệm mở ra vô vàn khả năng mới, cho phép nhà phát triển kiểm soát hoàn toàn nội dung của bộ nhớ đệm. Thay vì dựa vào việc kết hợp các tiêu đề HTTP và tính năng heuristics tích hợp của trình duyệt, Memory Storage API (API Bộ nhớ đệm của bộ nhớ đệm) sẽ hiển thị phương pháp lưu vào bộ nhớ đệm dựa trên mã. API Bộ nhớ đệm đặc biệt hữu ích khi được gọi từ JavaScript của trình chạy dịch vụ.
Đợi đã... bạn có bộ nhớ đệm nào khác cần xem xét vào lúc này không?
Có thể bạn đang tự hỏi những câu như "Tôi vẫn cần định cấu hình tiêu đề HTTP của mình chứ?" và "Tôi có thể làm gì với bộ nhớ đệm mới này, điều mà bộ nhớ đệm HTTP không làm được?" Đừng lo—đó là những phản ứng tự nhiên.
Bạn vẫn nên định cấu hình các tiêu đề Cache-Control trên máy chủ web, ngay cả khi biết mình đang sử dụng API Bộ nhớ đệm. Thường thì bạn có thể không cần đặt Cache-Control: no-cache cho các URL chưa được tạo phiên bản và/hoặc Cache-Control: max-age=31536000 cho các URL chứa thông tin phiên bản, chẳng hạn như hàm băm.
Khi điền vào bộ nhớ đệm API Bộ nhớ đệm, trình duyệt mặc định kiểm tra các mục hiện có trong bộ nhớ đệm HTTP và sử dụng các mục nhập đó nếu tìm thấy. Nếu bạn đang thêm URL có phiên bản vào bộ nhớ đệm của cache Storage API, thì trình duyệt sẽ tránh được một yêu cầu mạng bổ sung. Mặt khác của vấn đề này là nếu bạn đang sử dụng các tiêu đề Cache-Control được định cấu hình sai, chẳng hạn như chỉ định thời gian tồn tại của bộ nhớ đệm tồn tại trong thời gian dài cho một URL chưa được tạo phiên bản, thì bạn có thể làm mọi việc trở nên tệ hơn bằng cách thêm nội dung lỗi thời đó vào API Bộ nhớ bộ nhớ đệm. Sắp xếp hành vi bộ nhớ đệm HTTP
là điều kiện tiên quyết để sử dụng bộ nhớ đệm API một cách hiệu quả.
Đối với những gì hiện có thể thực hiện với API mới này, thì câu trả lời là: rất nhiều. Sau đây là một số cách sử dụng phổ biến mà bộ nhớ đệm HTTP sẽ gặp khó khăn hoặc không thể thực hiện được:
- Sử dụng phương pháp "làm mới trong nền" đối với nội dung đã lưu vào bộ nhớ đệm, còn gọi là lỗi thời trong khi xác thực lại.
- Đặt giới hạn về số lượng thành phần tối đa cần lưu vào bộ nhớ đệm và triển khai chính sách hết hạn tuỳ chỉnh để xoá các mục sau khi đạt đến giới hạn đó.
- So sánh phản hồi mới của mạng và đã lưu vào bộ nhớ đệm trước đó để xem có gì thay đổi không, đồng thời cho phép người dùng cập nhật nội dung (ví dụ: bằng một nút) khi dữ liệu thực sự được cập nhật.
Hãy xem API Bộ nhớ đệm: Hướng dẫn nhanh để tìm hiểu thêm.
Đai ốc và bu lông API
Có một số điều cần lưu ý về thiết kế của API:
- Các đối tượng
Requestđược dùng làm khoá duy nhất khi đọc và ghi vào các bộ nhớ đệm này. Để thuận tiện, bạn có thể chuyển vào một chuỗi URL như'https://example.com/index.html'làm khoá thay vì một đối tượngRequestthực tế và API sẽ tự động xử lý việc đó cho bạn. - Các đối tượng
Responseđược dùng làm giá trị trong các bộ nhớ đệm này. - Tiêu đề
Cache-Controltrên mộtResponsenhất định sẽ bị bỏ qua một cách hiệu quả khi lưu dữ liệu vào bộ nhớ đệm. Không có tính năng tự động kiểm tra thời hạn hoặc độ mới được tích hợp sẵn. Sau khi bạn lưu trữ một mục trong bộ nhớ đệm, mục đó sẽ vẫn tồn tại cho đến khi mã của bạn xoá mục đó một cách rõ ràng. (Có nhiều thư viện để thay mặt bạn đơn giản hoá việc bảo trì bộ nhớ đệm. Chúng tôi sẽ đề cập đến các nội dung đó ở phần sau trong loạt video này.) - Không giống như các API đồng bộ và cũ hơn như
LocalStorage, tất cả hoạt động của API Bộ nhớ đệm đều không đồng bộ.
Đường vòng nhanh: hứa hẹn và không đồng bộ/chờ
Trình chạy dịch vụ và API Bộ nhớ đệm sử dụng các khái niệm lập trình không đồng bộ.
Cụ thể, các đối tượng này chủ yếu dựa vào lời hứa để biểu thị kết quả trong tương lai của hoạt động không đồng bộ. Bạn nên làm quen với lời hứa và cú pháp async/await có liên quan trước khi tìm hiểu sâu hơn.
Chưa triển khai mã đó...
Mặc dù chúng cung cấp nền tảng quan trọng và có thể được sử dụng nguyên trạng, nhưng cả trình chạy dịch vụ và API Bộ nhớ đệm đều là các thành phần cấp thấp hơn một cách hiệu quả, với một số trường hợp hiếm gặp và "giao diện" (gotcha). Có một số công cụ cấp cao hơn có thể giúp làm mượt những đoạn khó của những API đó và cung cấp tất cả những gì bạn cần để tạo một trình chạy dịch vụ sẵn sàng cho việc sản xuất. Hướng dẫn tiếp theo đề cập đến một công cụ như vậy: WorkManager.