Google sử dụng công nghệ AI để dịch nội dung sang ngôn ngữ bạn ưu tiên. Bản dịch bằng AI có thể có lỗi.

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

Jeff Posnick

Bạn đang phải nỗ lực để đảm bảo độ tin cậy của mạng. Bộ nhớ đệm HTTP của trình duyệt là tuyến phòng thủ đầu tiê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 đó. Chỉ riêng bộ nhớ đệm HTTP là chưa đủ.

May mắn thay, có hai công cụ mới hơn giúp bạn xoay chuyển tình thế theo hướng có lợi cho mình: 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 đoạn 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 bạn.

Trình chạy dịch vụ có một số quyền đặc biệt. Trong số các nhiệm vụ khác, trình chạy dịch vụ kiên nhẫn chờ ứng dụng web của bạn đưa ra yêu cầu gửi đi, sau đó bắt đầu hoạt động bằng cách chặn yêu cầu đó. Việc trình chạy dịch vụ làm gì với yêu cầu bị chặn này là tuỳ thuộc vào bạn.

Đố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 đến mạng, giống như những gì 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 giải pháp 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 cần phải lo lắng về mạng. Điều đó đòi hỏi bạn phải sử dụng một phần khác của câu đố: Cache Storage API.

Cache Storage API

Browser Support

Source

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

Khoan đã… giờ còn có một bộ nhớ đệm khác cần xem xét nữa sao?

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 bạn biết rằng mình đang sử dụng Cache Storage API. Bạn thường có thể bỏ qua việc đặ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 về phiên bản, chẳng hạn như hàm băm.

Khi điền sẵn bộ nhớ đệm Cache Storage API, 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 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, nếu bạn đang sử dụng các tiêu đề Cache-Control bị định cấu hình sai, chẳng hạn như chỉ định thời gian lưu vào bộ nhớ đệm lâu dài cho một URL không có phiên bản, thì bạn có thể làm cho mọi thứ trở nên tồi tệ hơn bằng cách thêm nội dung cũ đó vào Cache Storage API. Việc sắp xếp hành vi của bộ nhớ đệm HTTP là điều kiện tiên quyết để sử dụng hiệu quả Cache Storage API.

API mới này có thể làm được rất nhiều việc. Một số trường hợp sử dụng phổ biến mà bạn sẽ khó hoặc không thể thực hiện nếu chỉ dùng bộ nhớ đệm HTTP bao gồm:

Sử dụng phương pháp "làm mới trong nền" cho nội dung được lưu vào bộ nhớ đệm, còn gọi là stale-while-revalidate.
Áp đặ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ạng mới và phản hồi đã lưu vào bộ nhớ đệm trước đó để xem có thay đổi gì 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 bài viết The Cache API: A quick guide (API Bộ nhớ đệm: Hướng dẫn nhanh) để tìm hiểu thêm.

Chi tiết 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 khi lưu dữ liệu vào bộ nhớ đệm. Không có quy trình kiểm tra tự động, tích hợp sẵn về thời hạn hoặc độ mới, 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 duy trì bộ nhớ đệm thay cho bạn. Chúng ta sẽ tìm hiểu về các thành phần này trong phần sau của loạt video này.)
Không giống như các API đồng bộ cũ hơn, chẳng hạn như LocalStorage, tất cả thao tác của Cache Storage API đều không đồng bộ.

Một chút thông tin bên lề: Lời hứa 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 thư viện này phụ thuộc rất nhiều vào 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.

Đừng triển khai mã đó… ngay bây giờ

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