Xây dựng nhiều Ứng dụng web tiến bộ trên cùng một miền

Cách tạo nhiều PWA, tận dụng cùng một tên miền để cho người dùng biết rằng họ thuộc cùng một tổ chức hoặc dịch vụ.

Chase Phillips

Demián Renzulli

Matt Giuca

Trong bài đăng trên blog về Ứng dụng web tiến bộ trong trang web nhiều nguồn gốc, Demian đã thảo luận về những thách thức mà các trang web được xây dựng trên nhiều nguồn gốc gặp phải khi cố gắng xây dựng một Ứng dụng web tiến bộ bao gồm tất cả các nguồn gốc đó.

Ví dụ về loại cấu trúc trang web này là trang web thương mại điện tử, trong đó:

• Trang chủ nằm ở https://www.example.com.
• Các trang danh mục được lưu trữ tại https://category.example.com.
• Trang chi tiết sản phẩm tại https://product.example.com.

Như đã thảo luận trong bài viết, chính sách cùng nguồn gốc áp đặt một số hạn chế, ngăn việc chia sẻ trình chạy dịch vụ, bộ nhớ đệm và quyền trên các nguồn gốc. Vì lý do đó, bạn nên tránh loại cấu hình này và đối với những người đã tạo trang web theo cách này, hãy cân nhắc chuyển sang một cấu trúc trang web gốc duy nhất bất cứ khi nào có thể.

Trong bài đăng này, chúng ta sẽ xem xét trường hợp ngược lại: thay vì một PWA duy nhất trên nhiều nguồn gốc, chúng ta sẽ phân tích trường hợp các công ty muốn cung cấp nhiều PWA, tận dụng cùng một tên miền và giúp người dùng biết rằng các PWA đó thuộc cùng một tổ chức hoặc dịch vụ.

Như bạn có thể nhận thấy, chúng tôi đang sử dụng các thuật ngữ khác nhau nhưng có liên quan với nhau, chẳng hạn như miền và nguồn gốc. Trước khi chuyển sang phần tiếp theo, hãy cùng xem lại các khái niệm này.

Điều khoản kỹ thuật

• Miền: Mọi trình tự nhãn được xác định trong Hệ thống tên miền (DNS). Ví dụ: com và example.com là các miền.
• Tên máy chủ: Một mục DNS phân giải thành ít nhất một địa chỉ IP. Ví dụ: www.example.com sẽ là tên máy chủ, example.com có thể là tên máy chủ nếu có địa chỉ IP và com sẽ không bao giờ phân giải thành địa chỉ IP nên không bao giờ có thể là tên máy chủ.
• Nguồn gốc: Tổ hợp của một lược đồ, tên máy chủ và cổng (không bắt buộc). Ví dụ: https://www.example.com:443 là một nguồn gốc.

Như tên gọi, chính sách cùng nguồn gốc áp dụng các quy định hạn chế đối với nguồn gốc, vì vậy, chúng ta chủ yếu sẽ đề cập đến thuật ngữ này trong bài viết. Tuy nhiên, tuỳ từng thời điểm, chúng tôi sẽ sử dụng "miền" hoặc "miền con" để mô tả kỹ thuật đang dùng nhằm tạo ra các "nguồn gốc" khác nhau.

Trường hợp có nhiều PWA có liên quan

Trong một số trường hợp, bạn có thể muốn xây dựng các ứng dụng độc lập, nhưng vẫn xác định các ứng dụng đó thuộc cùng một tổ chức hoặc "thương hiệu". Việc sử dụng lại cùng một tên miền là một cách hay để thiết lập mối quan hệ đó. Ví dụ:

• Một trang web thương mại điện tử muốn tạo ra một trải nghiệm độc lập để người bán có thể quản lý kho hàng của mình, đồng thời đảm bảo họ hiểu rằng trang web đó thuộc về trang web chính nơi người dùng mua sản phẩm.
• Một trang web tin tức thể thao muốn xây dựng một ứng dụng cụ thể cho một sự kiện thể thao lớn, để cho phép người dùng nhận số liệu thống kê về các cuộc thi mà họ yêu thích thông qua thông báo và cài đặt ứng dụng đó dưới dạng Ứng dụng web tiến bộ, đồng thời đảm bảo rằng người dùng nhận ra đó là ứng dụng do công ty tin tức xây dựng.
• Một công ty muốn xây dựng các ứng dụng trò chuyện, email và lịch riêng biệt và muốn các ứng dụng này hoạt động như các ứng dụng riêng lẻ, liên kết với tên của công ty.

Sử dụng các nguồn gốc riêng biệt

Phương pháp được đề xuất trong những trường hợp như vậy là mỗi ứng dụng khác nhau về mặt khái niệm sẽ hoạt động trên nguồn gốc riêng.

Nếu muốn sử dụng cùng một tên miền trong tất cả các trang web, bạn có thể làm việc đó bằng cách sử dụng miền con. Ví dụ: một công ty cung cấp nhiều ứng dụng hoặc dịch vụ Internet có thể lưu trữ một ứng dụng thư tại https://mail.example.com và một ứng dụng lịch tại https://calendar.example.com, trong khi vẫn cung cấp dịch vụ chính của doanh nghiệp tại https://www.example.com. Một ví dụ khác là một trang web thể thao muốn tạo một ứng dụng độc lập hoàn toàn dành riêng cho một sự kiện thể thao quan trọng, chẳng hạn như giải vô địch bóng đá tại https://footballcup.example.com, mà người dùng có thể cài đặt và sử dụng độc lập với trang web thể thao chính, được lưu trữ tại https://www.example.com. Phương pháp này cũng có thể hữu ích cho các nền tảng cho phép khách hàng tạo ứng dụng độc lập của riêng họ dưới thương hiệu của công ty. Ví dụ: một ứng dụng cho phép người bán tạo PWA của riêng họ tại https://merchant1.example.com, https://merchant2.example.com, v.v.

Việc sử dụng nhiều nguồn gốc giúp đảm bảo sự tách biệt giữa các ứng dụng, nghĩa là mỗi ứng dụng có thể quản lý các tính năng của trình duyệt một cách độc lập, bao gồm:

• Khả năng cài đặt: Mỗi ứng dụng đều có Tệp kê khai riêng và cung cấp trải nghiệm có thể cài đặt riêng.
• Bộ nhớ: Mỗi ứng dụng có bộ nhớ đệm, bộ nhớ cục bộ riêng và về cơ bản là tất cả các dạng bộ nhớ cục bộ trên thiết bị mà không chia sẻ với các ứng dụng khác.
• Trình chạy dịch vụ: Mỗi ứng dụng có một trình chạy dịch vụ riêng cho các phạm vi đã đăng ký.
• Quyền: Quyền cũng được phân phạm vi theo nguồn gốc. Nhờ đó, người dùng sẽ biết chính xác dịch vụ nào họ đang cấp quyền và các tính năng như thông báo sẽ được phân bổ đúng cách cho từng ứng dụng.

Việc tạo mức độ tách biệt như vậy là điều mong muốn nhất trong trường hợp sử dụng nhiều PWA độc lập, vì vậy, bạn nên dùng phương pháp này.

Nếu muốn chia sẻ dữ liệu cục bộ với nhau, các ứng dụng trên miền con vẫn có thể thực hiện việc này thông qua cookie hoặc đối với các trường hợp nâng cao hơn, các ứng dụng có thể cân nhắc việc đồng bộ hoá bộ nhớ thông qua máy chủ.

Sử dụng cùng một nguồn gốc

Phương pháp thứ hai là xây dựng nhiều PWA trên cùng một nguồn gốc. Điều này bao gồm các trường hợp sau:

Các đường dẫn không trùng lặp

Nhiều PWA hoặc "ứng dụng web" mang tính khái niệm, được lưu trữ trên cùng một nguồn gốc, với các đường dẫn không trùng lặp. Ví dụ:

• https://example.com/app1/
• https://example.com/app2/

Đường dẫn chồng chéo/lồng nhau

Nhiều PWA trên cùng một nguồn gốc, trong đó phạm vi của một PWA được lồng bên trong phạm vi của PWA khác:

• https://example.com/ ("ứng dụng bên ngoài")
• https://example.com/app/ ("ứng dụng bên trong")

API trình chạy dịch vụ và định dạng tệp kê khai cho phép bạn thực hiện một trong hai thao tác trên bằng cách sử dụng phạm vi cấp đường dẫn. Tuy nhiên, trong cả hai trường hợp, việc sử dụng cùng một nguồn gốc sẽ gây ra nhiều vấn đề và hạn chế, nguyên nhân chính là do trình duyệt sẽ không xem xét đầy đủ những ứng dụng này là "ứng dụng" riêng biệt, do đó không nên sử dụng phương pháp này.

Trong phần tiếp theo, chúng ta sẽ phân tích chi tiết hơn về những thách thức này và những việc có thể làm nếu không thể sử dụng các nguồn gốc riêng biệt.

Thách thức đối với nhiều PWA cùng nguồn gốc

Dưới đây là một số vấn đề thực tế thường gặp đối với cả hai phương pháp cùng nguồn gốc:

• Bộ nhớ: Cookie, bộ nhớ cục bộ và mọi hình thức bộ nhớ cục bộ trên thiết bị được chia sẻ giữa các ứng dụng. Vì lý do đó, nếu người dùng quyết định xoá dữ liệu cục bộ cho một ứng dụng, thì thao tác này sẽ xoá tất cả dữ liệu khỏi nguồn gốc; không có cách nào để thực hiện việc này cho một ứng dụng. Xin lưu ý rằng Chrome và một số trình duyệt khác sẽ chủ động nhắc người dùng xoá dữ liệu cục bộ khi gỡ cài đặt một trong các ứng dụng, và việc này cũng sẽ ảnh hưởng đến dữ liệu của các ứng dụng khác trên nguồn gốc. Một vấn đề khác là các ứng dụng cũng sẽ phải chia sẻ hạn mức bộ nhớ, tức là nếu một trong hai ứng dụng chiếm quá nhiều dung lượng, thì ứng dụng còn lại sẽ bị ảnh hưởng tiêu cực.
• Quyền: Các quyền của trình duyệt được liên kết với nguồn gốc. Điều đó có nghĩa là nếu người dùng cấp quyền cho một ứng dụng, thì quyền đó sẽ đồng thời áp dụng cho tất cả ứng dụng trên nguồn gốc đó. Điều này nghe có vẻ tốt (không phải yêu cầu quyền nhiều lần), nhưng hãy nhớ: nếu người dùng chặn quyền cho một ứng dụng, thì các ứng dụng khác sẽ không thể yêu cầu quyền đó hoặc sử dụng tính năng đó. Xin lưu ý rằng mặc dù bạn chỉ cần cấp quyền cho trình duyệt một lần cho mỗi nguồn gốc, nhưng bạn phải cấp quyền cấp hệ thống một lần cho mỗi ứng dụng, bất kể nhiều ứng dụng có trỏ đến cùng một nguồn gốc hay không.
• Chế độ cài đặt của người dùng: Các chế độ cài đặt cũng được thiết lập theo nguồn gốc. Ví dụ: nếu 2 ứng dụng có kích thước phông chữ khác nhau và người dùng chỉ muốn điều chỉnh mức phóng to trên một trong số các ứng dụng đó để bù đắp cho kích thước phông chữ đó, thì họ sẽ không thể thực hiện việc này nếu không áp dụng chế độ cài đặt này cho các ứng dụng khác.

Những thách thức này khiến chúng tôi khó có thể khuyến khích phương pháp này. Tuy nhiên, nếu bạn không thể sử dụng một nguồn gốc riêng biệt (ví dụ: một miền con), như đã thảo luận trong phần Sử dụng nguồn gốc riêng biệt, trong hai tuỳ chọn cùng nguồn gốc mà chúng tôi đã trình bày, bạn nên sử dụng các đường dẫn không trùng lặp thay vì các đường dẫn trùng lặp/lồng nhau.

Như đã đề cập, các thách thức được thảo luận trong phần này đều phổ biến đối với cả hai phương pháp cùng nguồn gốc. Trong phần tiếp theo, chúng ta sẽ tìm hiểu sâu hơn về lý do sử dụng đường dẫn trùng lặp/lồng nhau là chiến lược ít được đề xuất nhất.

Các thách thức khác đối với đường dẫn trùng lặp/lồng nhau

Một vấn đề khác khi sử dụng phương pháp đường dẫn chồng chéo/lồng nhau (trong đó https://example.com/ là ứng dụng bên ngoài và https://example.com/app/ là ứng dụng bên trong) là tất cả URL trong ứng dụng bên trong sẽ thực sự được coi là một phần của cả ứng dụng bên ngoài và ứng dụng bên trong.

Trong thực tế, điều này gây ra các vấn đề sau:

• Khuyến mãi cài đặt: Nếu người dùng truy cập vào ứng dụng bên trong (ví dụ: trong trình duyệt web), thì khi ứng dụng bên ngoài đã được cài đặt trong thiết bị của người dùng, trình duyệt sẽ không hiển thị biểu ngữ quảng bá về việc cài đặt và sự kiện trướcInstallPrompt sẽ không được kích hoạt. Lý do là trình duyệt sẽ kiểm tra xem trang hiện tại có thuộc về một ứng dụng đã cài đặt hay không và sẽ kết luận rằng trang đó thuộc về ứng dụng đó. Giải pháp cho vấn đề này là cài đặt ứng dụng bên trong theo cách thủ công (thông qua tuỳ chọn trình đơn "Tạo lối tắt") hoặc cài đặt ứng dụng bên trong trước ứng dụng bên ngoài.
• Thông báo và API gắn huy hiệu: Nếu ứng dụng bên ngoài được cài đặt nhưng ứng dụng bên trong chưa được cài đặt, thì thông báo và huy hiệu đến từ ứng dụng bên trong sẽ bị phân bổ nhầm cho ứng dụng bên ngoài (là phạm vi bao bọc gần nhất của một ứng dụng đã cài đặt). Tính năng này hoạt động đúng cách trong trường hợp cả hai ứng dụng đều được cài đặt trên thiết bị của người dùng.
• Ghi lại đường liên kết: Ứng dụng bên ngoài có thể ghi lại các URL thuộc về ứng dụng bên trong. Điều này đặc biệt có thể xảy ra nếu ứng dụng bên ngoài được cài đặt nhưng ứng dụng bên trong thì không. Tương tự như vậy, đường liên kết trong ứng dụng ngoài liên kết đến ứng dụng bên trong sẽ không liên kết với ứng dụng bên trong, vì chúng được coi là thuộc phạm vi của ứng dụng bên ngoài. Ngoài ra, trên ChromeOS và Android, nếu các ứng dụng này được thêm vào Cửa hàng Play (dưới dạng Hoạt động web đáng tin cậy), thì ứng dụng bên ngoài sẽ thu thập tất cả đường liên kết. Ngay cả khi ứng dụng bên trong được cài đặt, hệ điều hành vẫn sẽ cho phép người dùng chọn mở ứng dụng đó trong ứng dụng bên ngoài.

Kết luận

Trong bài viết này, chúng tôi đã xem xét nhiều cách mà nhà phát triển có thể xây dựng nhiều Ứng dụng web tiến bộ liên quan với nhau trong cùng một miền.

Tóm lại, bạn nên sử dụng một nguồn gốc khác (ví dụ: bằng cách sử dụng miền con) để lưu trữ các PWA độc lập. Việc lưu trữ các ứng dụng trên cùng một nguồn gốc gặp nhiều thách thức, chủ yếu là do trình duyệt sẽ không hoàn toàn coi đây là những ứng dụng riêng biệt.

• Nguồn gốc riêng biệt: Nên dùng
• Cùng nguồn gốc, đường dẫn không trùng lặp: Không nên
• Cùng nguồn gốc, đường dẫn trùng lặp/lồng nhau: Không nên dùng

Nếu không thể sử dụng nhiều nguồn gốc, bạn nên sử dụng các đường dẫn không trùng lặp (ví dụ: https://example.com/app1/ và https://example.com/app2/) thay vì sử dụng các đường dẫn trùng lặp hoặc lồng nhau, chẳng hạn như https://example.com/ (dành cho ứng dụng bên ngoài) và https://example.com/app/ (dành cho ứng dụng bên trong).

Tài nguyên khác

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

Xin cảm ơn những ý kiến đánh giá và đề xuất kỹ thuật của họ: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner và Darwin Huang

Ảnh chụp của Tim Mossholder trên Unsplash