Ứ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ộ trên các trang web có nhiều nguồn gốc.

Demián Renzulli

Ngày xuất bản: 19 tháng 8 năm 2019

Trước đây, việc sử dụng cấu trúc nhiều nguồn gốc có một số lợi thế. Đối với Ứng dụng web tiến bộ, phương pháp đó đặt ra nhiều thách thức. Cụ thể, chính sách cùng nguồn gốc áp đặt các quy định hạn chế đối với việc chia sẻ những nội dung như trình chạy dịch vụ và bộ nhớ đệm, quyền và để đạt được trải nghiệm độc lập trên nhiều nguồn gốc.

Khám phá cách sử dụng nhiều nguồn gốc theo cách tốt và xấu, đồ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ộ trên các trang web có 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 tập hợp ứ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, cũng có những trường hợp nên tránh sử dụng.

Điểm tốt

Trước tiên, hãy xem các 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 ở nhiều quốc gia (ví dụ: https://www.google.com.ar) hoặc sử dụng miền con để phân chia các trang web được nhắm đến nhiều vị trí (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 các miền con khác nhau để 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, ứng dụng web trò chơi ô chữ có thể được phân phát một cách có chủ đích từ https://crosswords.example.com, đồng thời được 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 với trang web chính.

Mặt xấu

Nếu bạn không làm bất kỳ điều nào trong số này, thì có thể việc sử dụng cấu trúc nhiều nguồn gốc sẽ là một bất lợi khi xây dựng Ứ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 "kế thừa". Một ví dụ là việc sử dụng miền con để phân tách tuỳ ý các phần của một trang web mà lẽ ra 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:

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

• Luồng người dùng: Một phương pháp khác không được khuyến khích là tách các phần nhỏ hơn của trang web, chẳng hạn như các trang cho luồng đăng nhập hoặc quy trình mua 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 nên tránh chia trang web thành các miền con. Đối với các trang web hiện có, việc di chuyển sang một nguồn gốc duy nhất là phương pháp hay 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ể) giải pháp có thể cân nhắc khi xây dựng Ứng dụng web tiến bộ.

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 là một thách thức, chủ yếu là do chính sách cùng nguồn gốc áp đặt một số quy tắc ràng buộc. Hãy cùng tìm hiểu từng loại.

Trình chạy dịch vụ

Nguồn gốc của URL tập lệnh trình chạy dịch vụ phải giống với nguồn gốc của trang gọi register(). Điều này có nghĩa là, ví dụ: một trang tại https://www.example.com không thể gọi register() bằng URL trình chạy dịch vụ tại https://section.example.com.

Một điểm khác cần lưu ý là trình chạy dịch vụ chỉ có thể kiểm soát các trang được lưu trữ theo 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 đó chỉ có thể kiểm soát các URL từ nguồn gốc đó (theo đường dẫn được xác định trong tham 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ỗi trình chạy dịch vụ cho một nguồn gốc).

Thận trọng: Việc đăng ký và có nhiều trình chạy 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 cân nhắc kỹ về số lượng trình chạy dịch vụ đang hoạt động mà người dùng có thể cần để di chuyển trên trang web.

Đang lưu vào bộ nhớ đệm

Đối tượng Cache, 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 về https://www.example.com, chẳng hạn như từ: 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 những trường hợp như sau:

• Tận dụng bộ nhớ đệm của trình duyệt: Bạn nên sử dụng các phương pháp hay nhất về bộ nhớ đệm truyền thống của trình duyệt. Kỹ thuật này mang lại lợi ích bổ sung là sử dụng lại tài nguyên đã lưu vào bộ nhớ đệm trên nhiều nguồn gốc, điều mà bộ nhớ đệm của trình chạy dịch vụ không thể thực hiện được. Để 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 trình chạy dịch vụ luôn gọn nhẹ: Nếu bạn đang duy trì nhiều trình chạy dịch vụ, hãy tránh khiến người dùng phải trả 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 trước vào bộ nhớ đệm những tài nguyên thực sự cần thiết.

Sau khi trình chạy dịch vụ 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 khác nguồn gốc được thực hiện bên trong trình chạy dịch vụ. May mắn là có một giải pháp đề xuất cho vấn đề này, đó là sử dụng CORS (như giải thích tại đây). Bạn không nên sử dụng chế độ no-cors khi tìm nạp tài nguyên bên trong trình chạy dịch vụ.

Quyền

Các quyền cũng được đặt phạm vi cho các 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 giữa các nguồn gốc, nên giải pháp duy nhất ở đây là yêu cầu quyền trên mỗi miền con cần có một tính năng nhất định (ví dụ: vị trí). Đối với những tính năng như thông báo đẩy trên 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, nhằm tránh yêu cầu lại.

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 một start_url liên quan đến chính nguồn gốc đó. Đ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 (tức là: https://section.example.com) sẽ không thể cài đặt PWA có start_url trên một nguồn gốc khác (tức là: 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òn có vấn đề là cùng một người dùng có thể nhận được nhiều lời nhắc cài đặt khi di chuyển trên trang web, nếu mỗi miền con đều đáp ứng 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. Lắng nghe sự kiện beforeinstallprompt.
2. Ngăn lời nhắc xuất hiện, 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 trên 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 gốc 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 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. 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 trong 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 giải pháp tạm thời 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 nhiệm 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 thu được từ iframe trở lại trang gốc.
3. Bước cuối cùng, sau khi trang chính nhận được thông báo, trình nghe có thể bị huỷ đăng ký và iframe cuối cùng sẽ bị xoá khỏi DOM.

Thận trọng: Kỹ thuật trước đó có thể giúp giảm thiểu khả năng thay đổi giao diện người dùng ở 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 miền con và quay lại nguồn gốc chính (như trong quy trình đăng nhập), nhưng sẽ không phải là một 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 (như toàn bộ các phần của trang web).

Lưu ý: Trong bối cảnh của Hoạt động web đáng tin cậy, bạn nên tránh vấn đề này bằng cách xác thực tất cả cá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 các 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 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, việc làm cho PWA đa nguồn hoạt động chính xác có thể gặp nhiều khó khăn, nhưng chúng tôi đã khám phá một số giải pháp tiềm năng. Mỗi phương pháp đều có ưu và nhược điểm, vì vậy, hãy cân nhắc kỹ khi quyết định áp dụng phương pháp nào cho 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 duy nhất, trừ phi có lý do quan trọng để giữ lại cấu trúc nhiều nguồn gốc.

Xin chân thành cảm ơn những ý kiến đánh giá và đề xuất về mặt kỹ thuật của: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle và Andre Bandarra.