Trang này được dịch bởi Cloud Translation API.

Trình chạy dịch vụ và API Bộ nhớ đệm

Jeff Posnick

Bạn đang phải vật lộn để đảm bảo độ tin cậy của mạng. Bộ nhớ đệm HTTP của trình duyệt là hàng phòng thủ đầu tiên của bạn, nhưng như bạn đã biết, 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ộ nhớ đệm HTTP không đủ.

May mắn thay, có hai công cụ mới hơn có thể giúp bạn xoay chuyển tình thế: trình chạy dịch vụ và API bộ nhớ đệm. 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 kiểm soát bằng một chút 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ế.

Worker dịch vụ có một số quyền đặc biệt. Ngoài các nhiệm vụ khác, trình chặn này kiên nhẫn chờ ứng dụng web của bạn đưa ra một yêu cầu gửi đi, sau đó bắt đầu hành động bằng cách chặn yêu cầu đó. Bạn có thể quyết định việc trình chạy dịch vụ sẽ làm gì với yêu cầu bị chặn này.

Đối với một số yêu cầu, cách tốt nhất có thể chỉ là cho phép yêu cầu tiếp tục chuyển đến mạng, giống như những gì sẽ xảy ra nếu không có worker 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 phương thức linh hoạt hơn bộ nhớ đệm HTTP của trình duyệt và trả về phản hồi nhanh và đáng tin cậy mà không phải lo lắng về mạng. Điều đó đòi hỏi bạn phải sử dụng phần còn lại của câu đố: API Bộ nhớ đệm.

API Bộ nhớ đệm

Browser Support

Source

API Bộ nhớ đệm mở ra một loạt khả năng mới, bằng cách cho phép nhà phát triển kiểm soát toàn bộ nội dung của bộ nhớ đệm. Thay vì dựa vào kết hợp các tiêu đề HTTP và phương thức phỏng đoán tích hợp sẵn của trình duyệt, API Bộ nhớ cache sẽ hiển thị phương pháp dựa trên mã để lưu vào bộ nhớ đệm. API Bộ nhớ đệm đặc biệt hữu ích khi được gọi từ JavaScript của worker dịch vụ.

Chờ đã… có một bộ nhớ đệm khác mà bạn cần cân nhắc không?

Có thể bạn đang tự hỏi những câu hỏi như "Tôi có cần định cấu hình tiêu đề HTTP không?" và "Tôi có thể làm gì với bộ nhớ đệm mới này mà không thể làm được với bộ nhớ đệm HTTP?" Đừng lo, đó là những phản ứng tự nhiên.

Bạn vẫn nên định cấu hình tiêu đề Cache-Control trên máy chủ web, ngay cả khi biết rằng mình đang sử dụng API Bộ nhớ đệm. Thông thường, bạn có thể đặt Cache-Control: no-cache cho các URL không có 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 bộ nhớ đệm API Bộ nhớ đệm, trình duyệt mặc định sẽ kiểm tra các mục hiện có trong bộ nhớ đệm HTTP và sử dụng các mục đó nếu tìm thấy. Nếu bạn đang thêm URL có phiên bản vào bộ nhớ đệm API Bộ nhớ đệm, trình duyệt sẽ tránh gửi thêm yêu cầu mạng. Mặt khác, nếu đang sử dụng tiêu đề Cache-Control được định cấu hình không chính xác, chẳng hạn như chỉ định thời gian lưu trữ bộ nhớ đệm lâu dài cho một URL chưa có phiên bản, thì bạn có thể khiến mọi thứ trở nên tệ hơn bằng cách thêm nội dung cũ đó vào API Bộ nhớ đệm. Việc sắp xếp hành vi bộ nhớ đệm HTTP là điều kiện tiên quyết để sử dụng hiệu quả API Bộ nhớ đệm.

Đối với những gì hiện có thể làm được với API mới này, câu trả lời là: rất nhiều. Sau đây là một số trường hợp sử dụng phổ biến sẽ khó hoặc không thể thực hiện được nếu chỉ có bộ nhớ đệm HTTP:

Sử dụng phương pháp "làm mới ở chế độ nền" cho nội dung được lưu vào bộ nhớ đệm, còn gọi là lỗi thời trong khi xác thực lại.
Áp dụng giới hạn về số lượng thành phần tối đa để 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 khi đạt đến giới hạn đó.
So sánh các phản hồi mạng mới và đã lưu vào bộ nhớ đệm trước đó để xem có gì thay đổi không và 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 bài viết Cache API: Hướng dẫn nhanh để tìm hiểu thêm.

Thông tin cơ bản về 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ể truyền một chuỗi URL như 'https://example.com/index.html' làm khoá thay vì đối tượng Request thự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-Control trên một Response nhấ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 kiểm tra thời gian hết hạn hoặc độ mới tự động, tích hợp sẵn và sau khi bạn lưu trữ một mục trong bộ nhớ đệm, mục đó sẽ tồn tại cho đến khi mã của bạn xoá mục đó một cách rõ ràng. (Có các thư viện giúp đơn giản hoá việc bảo trì bộ nhớ đệm thay mặt cho bạn. Chúng ta sẽ đề cập đến các lớp này ở phần sau của loạt bài này.)
Không giống như các API đồng bộ cũ như LocalStorage, tất cả các thao tác của API Bộ nhớ đệm đều không đồng bộ.

Một điểm chuyển hướng nhanh: lời hứa và không đồng bộ/chờ

Worker 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 phương thức này chủ yếu dựa vào các lời hứa để thể hiện kết quả trong tương lai của các thao tác không đồng bộ. Bạn nên làm quen với lời hứa và cú pháp async/await liên quan trước khi bắt đầu tìm hiểu.

Đừng triển khai mã đó…

Mặc dù cung cấp một nền tảng quan trọng và có thể được sử dụng như hiện tại, nhưng cả worker dịch vụ và API bộ nhớ đệm đều là các khối xây dựng 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à "bẫy". Có một số công cụ cấp cao hơn có thể giúp bạn giải quyết các phần khó khăn của các API đó và cung cấp mọi thứ bạn cần để xây dựng một worker dịch vụ sẵn sàng cho bản phát hành chính thức. Hướng dẫn tiếp theo sẽ trình bày về một công cụ như vậy: Workbox.