Ứng dụng web tiến bộ trên các trang web nhiều nguồn gốc

Những thách thức và giải pháp để xây dựng Ứng dụng web tiến bộ trong các trang web đa nguồn gốc.

Demián Renzulli

Thông tin khái quát

Trước đây, việc sử dụng cấu trúc nhiều nguồn gốc có một số ưu điểm, nhưng đối với Ứng dụng web tiến bộ, phương pháp đó lại gây ra nhiều thách thức. Cụ thể, chính sách cùng nguồn gốc áp dụng các quy định hạn chế đối với việc chia sẻ các thành phần như trình chạy dịch vụ và bộ nhớ đệm, quyền cũng như để đạt được trải nghiệm độc lập trên nhiều nguồn gốc. Bài viết này sẽ mô tả những ưu và khuyết điểm của việc sử dụng nhiều nguồn gốc, đồng thời giải thích các thách thức và giải pháp để xây dựng Ứng dụng web tiến bộ trong các trang web nhiều nguồn gốc.

Cách sử dụng nhiều nguồn gốc đúng và sai

Có một số lý do chính đáng để các trang web sử dụng cấu trúc nhiều nguồn gốc, chủ yếu liên quan đến việc cung cấp một bộ ứng dụng web độc lập hoặc tạo ra trải nghiệm hoàn toàn tách biệt với nhau. Ngoài ra, bạn cũng nên tránh sử dụng API này cho một số mục đích.

Điểm tốt

Trước tiên, hãy xem xét những lý do hữu ích:

• Bản địa hoá / Ngôn ngữ: Sử dụng miền cấp cao nhất theo mã quốc gia để phân tách các trang web được phân phát ở các quốc gia khác nhau (ví dụ: https://www.google.com.ar) hoặc sử dụng miền con để phân chia các trang web nhắm đến các vị trí khác nhau (ví dụ: https://newyork.craigslist.org) hoặc để cung cấp nội dung cho một ngôn ngữ cụ thể (ví dụ: https://en.wikipedia.org).

• Ứng dụng web độc lập: Sử dụng nhiều miền con để cung cấp trải nghiệm có mục đích khác biệt đáng kể so với trang web trên nguồn gốc chính. Ví dụ: trong một trang web tin tức, bạn có thể chủ ý phân phát webapp ô chữ từ https://crosswords.example.com, đồng thời cài đặt và sử dụng dưới dạng một PWA độc lập mà không cần chia sẻ tài nguyên hoặc chức năng nào với trang web chính.

Điểm yếu

Nếu bạn không làm bất kỳ việc nào trong số này, thì việc sử dụng cấu trúc nhiều nguồn gốc có thể sẽ là một bất lợi khi tạo Ứng dụng web tiến bộ.

Mặc dù vậy, nhiều trang web vẫn tiếp tục được cấu trúc theo cách này mà không có lý do cụ thể hoặc vì lý do "cũ". Ví dụ: sử dụng miền con để phân tách tuỳ ý các phần của trang web vốn phải là một phần của trải nghiệm hợp nhất.

Ví dụ: bạn không nên sử dụng các mẫu sau:

• Các phần của trang web: Phân tách các phần khác nhau của trang web trên các miền con. Trong các trang web tin tức, bạn thường thấy trang chủ ở: https://www.example.com, trong khi mục thể thao nằm ở https://sports.example.com, mục chính trị nằm ở https://politics.example.com, v.v. Trong trường hợp trang web thương mại điện tử, hãy sử dụng các giá trị như https://category.example.com cho danh mục sản phẩm, https://product.example.com cho trang sản phẩm, v.v.

• Quy trình của người dùng: Bạn không nên tách riêng các phần nhỏ hơn của trang web, chẳng hạn như các trang cho quy trình đăng nhập hoặc mua hàng trong miền con. Ví dụ: sử dụng https://login.example.com và https://checkout.example.com.

Lưu ý: Khi xây dựng một trang web từ đầu, bạn không nên chia trang web đó thành các miền con. Đối với các trang web hiện có, phương pháp tốt nhất là di chuyển sang một nguồn gốc duy nhất.

Đối với những trường hợp không thể di chuyển sang một nguồn gốc duy nhất, sau đây là danh sách các thách thức và (nếu có thể) các giải pháp có thể được xem xét khi xây dựng Ứng dụng web tiến bộ.

Các thách thức và giải pháp cho PWA trên nhiều nguồn gốc

Khi xây dựng một trang web trên nhiều nguồn gốc, việc cung cấp trải nghiệm PWA hợp nhất sẽ gặp nhiều thách thức, chủ yếu là do chính sách về cùng một nguồn gốc áp đặt một số quy tắc ràng buộc. Hãy cùng xem xét từng loại.

Trình chạy dịch vụ

Nguồn gốc của URL tập lệnh worker phải giống với nguồn gốc của trang gọi register(). Ví dụ: một trang tại https://www.example.com không thể gọi register() bằng URL worker tại https://section.example.com.

Một điều cần cân nhắc khác là trình chạy dịch vụ chỉ có thể kiểm soát các trang được lưu trữ trong nguồn gốc và đường dẫn mà trình chạy dịch vụ đó thuộc về. Điều này có nghĩa là nếu trình chạy dịch vụ được lưu trữ tại https://www.example.com, thì trình chạy dịch vụ đó chỉ có thể kiểm soát các URL từ nguồn gốc đó (theo đường dẫn được xác định trong thông số phạm vi), nhưng sẽ không kiểm soát bất kỳ trang nào trong các miền con khác, chẳng hạn như các trang trong https://section.example.com.

Trong trường hợp này, giải pháp duy nhất là sử dụng nhiều trình chạy dịch vụ (một trình chạy cho mỗi nguồn gốc).

Thận trọng: Việc đăng ký và có nhiều worker dịch vụ đang hoạt động sẽ tiêu tốn thêm tài nguyên (bộ nhớ, CPU, v.v.). Vì vậy, hãy đánh giá kỹ số lượng worker dịch vụ đang hoạt động mà người dùng có thể cần để di chuyển trên trang web.

Lưu vào bộ nhớ đệm

Đối tượng Bộ nhớ đệm, indexedDB và localStorage cũng bị ràng buộc với một nguồn gốc duy nhất. Điều này có nghĩa là bạn không thể truy cập vào bộ nhớ đệm thuộc https://www.example.com, chẳng hạn như: https://www.section.example.com.

Sau đây là một số việc bạn có thể làm để quản lý bộ nhớ đệm đúng cách trong các trường hợp như thế này:

• Tận dụng tính năng lưu vào bộ nhớ đệm của trình duyệt: Bạn luôn nên sử dụng các phương pháp hay nhất để lưu vào bộ nhớ đệm của trình duyệt truyền thống. Kỹ thuật này mang lại thêm lợi ích là tái sử dụng các tài nguyên được lưu vào bộ nhớ đệm trên các nguồn gốc, điều mà bạn không thể thực hiện được với bộ nhớ đệm của worker dịch vụ. Để biết các phương pháp hay nhất về cách sử dụng Bộ nhớ đệm HTTP với trình chạy dịch vụ, bạn có thể xem bài đăng này.

• Giữ cho quá trình cài đặt worker dịch vụ nhẹ: Nếu bạn đang duy trì nhiều worker dịch vụ, hãy tránh khiến người dùng phải trả một khoản chi phí cài đặt lớn mỗi khi họ chuyển đến một nguồn gốc mới. Nói cách khác: chỉ lưu các tài nguyên cần thiết vào bộ nhớ đệm trước.

Sau khi worker dịch vụ đang hoạt động và chạy, chính sách cùng nguồn gốc cũng hạn chế các yêu cầu trên nhiều nguồn gốc được thực hiện bên trong worker dịch vụ. May mắn là bạn có thể khắc phục vấn đề này bằng cách sử dụng CORS (như giải thích tại đây). Bạn không nên sử dụng chế độ không có CORS khi tìm nạp tài nguyên bên trong worker dịch vụ.

Quyền

Quyền cũng được giới hạn trong phạm vi nguồn gốc. Điều này có nghĩa là nếu người dùng cấp một quyền nhất định cho nguồn gốc https://section.example.com, thì quyền đó sẽ không được chuyển sang các nguồn gốc khác, chẳng hạn như https://www.example.com.

Vì không có cách nào để chia sẻ quyền trên các nguồn gốc, nên giải pháp duy nhất ở đây là yêu cầu cấp quyền trên từng miền con cần có một tính năng nhất định (ví dụ: vị trí). Đối với các tính năng như thông báo đẩy web, bạn có thể duy trì một cookie để theo dõi xem người dùng đã chấp nhận quyền trong một miền con khác hay chưa, để tránh yêu cầu lại quyền.

Cài đặt

Để cài đặt một PWA, mỗi nguồn gốc phải có tệp kê khai riêng với start_url liên quan đến chính nó. Điều này có nghĩa là người dùng nhận được lời nhắc cài đặt trên một nguồn gốc nhất định (ví dụ: https://section.example.com) sẽ không thể cài đặt PWA bằng start_url trên một nguồn gốc khác (ví dụ: https://www.example.com). Nói cách khác, người dùng nhận được lời nhắc cài đặt trong một miền con sẽ chỉ có thể cài đặt PWA cho các trang con, chứ không phải cho URL chính của ứng dụng.

Ngoài ra, cùng một người dùng có thể nhận được nhiều lời nhắc cài đặt khi điều hướng trang web, nếu mỗi miền con đáp ứng các tiêu chí cài đặt và nhắc người dùng cài đặt PWA.

Để giảm thiểu vấn đề này, bạn có thể đảm bảo rằng lời nhắc chỉ xuất hiện trên nguồn gốc chính. Khi người dùng truy cập vào một miền con đáp ứng các tiêu chí cài đặt:

1. Nghe sự kiện beforeinstallprompt.
2. Ngăn lời nhắc xuất hiện bằng cách gọi event.preventDefault().

Bằng cách đó, bạn đảm bảo lời nhắc không xuất hiện ở những phần không mong muốn của trang web, trong khi bạn có thể tiếp tục hiển thị lời nhắc đó, chẳng hạn như ở nguồn chính (ví dụ: Trang chủ).

Chế độ độc lập

Khi điều hướng trong một cửa sổ độc lập, trình duyệt sẽ hoạt động theo cách khác khi người dùng di chuyển ra ngoài phạm vi do tệp kê khai của PWA đặt ra. Hành vi này phụ thuộc vào từng phiên bản trình duyệt và nhà cung cấp. Ví dụ: các phiên bản Chrome mới nhất sẽ mở một Thẻ tuỳ chỉnh của Chrome khi người dùng di chuyển ra khỏi phạm vi ở chế độ độc lập.

Trong hầu hết các trường hợp, không có giải pháp nào cho vấn đề này, nhưng bạn có thể áp dụng một giải pháp cho một số phần nhỏ của trải nghiệm được lưu trữ trong miền con (ví dụ: quy trình đăng nhập):

1. URL mới, https://login.example.com, có thể mở bên trong một iframe toàn màn hình.
2. Sau khi hoàn tất tác vụ bên trong iframe (ví dụ: quy trình đăng nhập), bạn có thể sử dụng postMessage() để chuyển mọi thông tin kết quả từ iframe trở lại trang mẹ.
3. Bước cuối cùng, sau khi trang chính nhận được thông báo, bạn có thể huỷ đăng ký trình nghe và cuối cùng xoá iframe khỏi DOM.

Thận trọng: Kỹ thuật trước đó có thể giúp giảm thiểu thay đổi có thể xảy ra đối với giao diện người dùng trong một phần nhỏ của trang web, nơi người dùng có thể thực hiện một hành động trong một miền con và quay lại nguồn gốc chính (chẳng hạn như trong quy trình đăng nhập), nhưng sẽ không phải là kỹ thuật hiệu quả để triển khai cho toàn bộ đường dẫn, bao gồm nhiều trang được lưu trữ trong miền con (chẳng hạn như toàn bộ phần trang web).

Lưu ý: Trong bối cảnh Hoạt động đáng tin cậy trên web, bạn nên tránh vấn đề này bằng cách xác thực tất cả nguồn gốc bằng Đường liên kết đến tài sản kỹ thuật số.

Kết luận

Chính sách cùng nguồn gốc áp đặt nhiều quy định hạn chế đối với những trang web được xây dựng dựa trên nhiều nguồn gốc muốn đạt được trải nghiệm PWA nhất quán. Vì lý do đó, để mang lại trải nghiệm tốt nhất cho người dùng, bạn không nên chia các trang web thành nhiều nguồn gốc.

Đối với các trang web hiện có được xây dựng theo cách này, có thể khó để làm cho PWA nhiều nguồn gốc hoạt động chính xác, nhưng chúng tôi đã khám phá một số giải pháp khả thi. Mỗi phương pháp đều có ưu và khuyết điểm. Vì vậy, hãy cân nhắc kỹ khi quyết định phương pháp nào phù hợp với trang web của bạn.

Khi đánh giá chiến lược dài hạn hoặc thiết kế lại trang web, hãy cân nhắc việc di chuyển sang một nguồn gốc, trừ phi có lý do quan trọng để giữ lại cấu trúc nhiều nguồn gốc.

Xin cảm ơn những người đã xem xét và đề xuất về mặt kỹ thuật: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle và Andre Bandarra.