Ứ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 cho việc xây dựng Ứng dụng web tiến bộ trên các trang web nhiều nguồn gốc.

Demián Renzulli

Thông tin khái quát

Trước đây, có một số ưu điểm khi sử dụng kiến trúc đa nguồn gốc, nhưng đố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 về 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 nội dung 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ả việc sử dụng nhiều nguồn gốc đúng cách và không đúng cách, đồng thời giải thích những thách thức và giải pháp cho việc xây dựng Ứng dụng web tiến bộ trên các trang web nhiều nguồn gốc.

Sử dụng tốt và không tốt của nhiều nguồn gốc

Có một vài lý do chính đáng để các trang web sử dụng kiến trúc nhiều nguồn gốc, chủ yếu liên quan đến việc cung cấp nhóm ứng dụng web độc lập hoặc tạo 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 nội dung này.

Ưu điểm

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 ở nhiều quốc gia (ví dụ: https://www.google.com.ar) hoặc sử dụng miền con để phân chia trang web được nhắm đến các vị trí khác nhau (ví dụ: https://newyork.craigslist.org) hoặc để cung cấp nội dung bằng một ngôn ngữ cụ thể (ví dụ: https://en.wikipedia.org).

• Các ứ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 đáng kể so với trang web gốc. Ví dụ: trong một trang web tin tức, ứng dụng web ô chữ có thể được phân phát một cách có chủ đích qua https://crosswords.example.com, đồng thời được cài đặt và sử dụng như một ứng dụng web tiến bộ (PWA) độc lập mà không cần phải chia sẻ tài nguyên hoặc chức năng nào với trang web chính.

Kém

Nếu bạn không thực hiện bất kỳ việc nào trong số này, thì có khả năng việc sử dụng kiến trúc đa 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 "cũ". Một ví dụ là sử dụng miền con để tuỳ ý tách biệt các phần của một trang web, vốn là một phần của một trải nghiệm hợp nhất.

Ví dụ: bạn tuyệt đối không nên sử dụng các mẫu sau đây:

• Các phần trang web: Phân tách các phần khác nhau của một trang web trên miền con. Trong các trang web tin tức, thường thấy trang chủ tại: https://www.example.com, trong khi chuyên mục thể thao trực tiếp tại https://sports.example.com, chuyên mục chính trị tại https://politics.example.com, v.v. Đối với trang web thương mại điện tử, hãy sử dụng tham số 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.

• 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, như các trang dành cho quy trình đă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 không nên chia trang web đó thành các miền con. Đối với các trang web hiện có, việc chuyển sang một nguồn gốc là phương pháp tốt nhất.

Đối với những trường hợp không thể di chuyển sang một nguồn gốc, 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ể xem xét 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 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 đặt ra một số hạn chế. Hãy cùng xem xét lần lượt từng mục.

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à, chẳng hạn một trang tại https://www.example.com không thể gọi register() bằng URL của trình chạy dịch vụ tại https://section.example.com.

Một 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ữ theo nguồn gốc và đường dẫn của trang đó. Tức 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 nà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ột trình chạy cho mỗi nguồn gốc).

Chú ý: 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 thật sáng suốt về số lượng trình chạy dịch vụ đang hoạt động mà một người dùng có thể cần di chuyển trên trang web.

Chức năng lưu vào bộ nhớ đệm

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

Dưới đâ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 tình huống 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 trình duyệt vào bộ nhớ đệm theo cách truyền thống. Kỹ thuật này mang đến thêm lợi ích là sử dụng lại các tài nguyên đã lưu vào bộ nhớ đệm giữa các nguồn gốc mà không thể thực hiện được với bộ nhớ đệm của trình chạy 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.

• Đảm bảo cài đặt trình chạy dịch vụ 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ọ điều hướng đến một nguồn gốc mới. Nói cách khác: chỉ lưu trước những tài nguyên thực sự cần thiết vào bộ nhớ đệm.

Khi trình chạy dịch vụ đang hoạt động và đang 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 trình thực thi dịch vụ. Rất may là trường hợp này có một giải pháp được đề xuất, đó là sử dụng CORS (như giải thích tại đây). Bạn không nên sử dụng chế độ không 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 thuộc phạm vi của các nguồn gốc. Điều này có nghĩa là nếu người dùng đã cấp quyền nhất định cho nguồn gốc https://section.example.com, thì quyền đó sẽ không 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 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 những vấn đề như tính năng đẩy trên web, bạn có thể duy trì 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 PWA, mỗi nguồn gốc phải có tệp kê khai riêng với start_url tương ứng với 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 (tức là https://section.example.com) sẽ không thể cài đặt PWA với start_url trên một nguồn 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 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, một vấn đề nữa 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 đá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ỉ hiển thị trên nguồn gốc chính. Khi người dùng truy cập vào miền con vượt qua tiêu chí cài đặt:

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

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

Chế độ độc lập

Trong khi di chuyển 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. 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 mở Thẻ tuỳ chỉnh của Chrome khi người dùng rời khỏi phạm vi ở chế độ độc lập.

Trong hầu hết trường hợp, không có giải pháp nào cho vấn đề này, nhưng có thể áp dụng một giải pháp cho những 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 iframe toàn màn hình.
2. Sau khi tác vụ đã hoàn tất 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 phát sinh từ iframe về trang chính.
3. Bước cuối cùng là sau khi trang chính nhận được thông báo, người 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 đây có thể giúp giảm thiểu sự thay đổi có thể xảy ra đối với giao diện người dùng trên 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 chính (như trong quy trình đăng nhập). Tuy nhiên, kỹ thuật này không phải là kỹ thuật hiệu quả để triển khai cho toàn bộ đường dẫn (bao gồm cả 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 trường hợp Hoạt động trên 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ả 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 dụng 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 có được trải nghiệm PWA nhất quán. 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 những trang web hiện có đã được tạo theo cách này, có thể khó khăn để đảm bảo các PWA nhiều nguồn gốc hoạt động chính xác, nhưng chúng tôi đã tìm hiểu một số giải pháp tiềm năng. Mỗi phương pháp đều có thể đi kèm với sự đánh đổi, vì vậy, hãy suy xét trước khi quyết định phương pháp nên thực hiện trên trang web của bạn.

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

Chúng tôi rất cảm ơn những ý kiến đánh giá và gợi ý về mặt kỹ thuật của họ: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle và Andre Bandarra.