Việc thiết kế ứng dụng để khai thác tối đa công nghệ giúp PWA trở nên đáng tin cậy, dễ cài đặt và có khả năng bắt đầu từ việc hiểu rõ ứng dụng và các hạn chế của ứng dụng, rồi chọn kiến trúc phù hợp cho cả hai.
SPA so với MPA
Ngày nay, có 2 mẫu kiến trúc chính trong quá trình phát triển web: ứng dụng trang đơn (SPA) và ứng dụng nhiều trang (MPA).
Ứng dụng trang đơn được xác định bằng cách yêu cầu JavaScript phía máy khách kiểm soát hầu hết hoặc toàn bộ quá trình hiển thị HTML của một trang dựa trên dữ liệu mà ứng dụng truy xuất hoặc cung cấp cho ứng dụng. Ứng dụng ghi đè tính năng điều hướng tích hợp của trình duyệt, thay thế bằng chức năng định tuyến và xử lý chế độ xem.
Ứng dụng nhiều trang thường gửi HTML được kết xuất trước trực tiếp đến trình duyệt, thường được tăng cường bằng JavaScript phía máy khách sau khi trình duyệt tải xong HTML, và dựa vào cơ chế điều hướng tích hợp trong trình duyệt để hiển thị các lượt xem tiếp theo.
Cả hai cấu trúc này đều có thể được dùng để tạo PWA.
Mỗi phương thức đều có ưu và nhược điểm riêng. Do đó, việc lựa chọn cách thức phù hợp với trường hợp sử dụng và bối cảnh của bạn là yếu tố then chốt để cung cấp trải nghiệm nhanh chóng và đáng tin cậy cho người dùng.
Ứng dụng trang đơn
- Chủ yếu là cập nhật trong trang không thể phân chia.
- Các phần phụ thuộc phía máy khách được tải khi khởi động.
- Các lần tải tiếp theo diễn ra nhanh do sử dụng bộ nhớ đệm.
- Chi phí tải ban đầu cao.
- Hiệu suất phụ thuộc vào phần cứng thiết bị và kết nối mạng.
- Ứng dụng cần có thêm sự phức tạp.
Ứng dụng trang đơn phù hợp về mặt cấu trúc nếu:
- Tương tác của người dùng chủ yếu tập trung vào các bản cập nhật không thể phân chia của dữ liệu liên kết hiển thị trên cùng một trang, chẳng hạn như trang tổng quan dữ liệu theo thời gian thực hoặc ứng dụng chỉnh sửa video.
- Ứng dụng của bạn có các phần phụ thuộc khởi động chỉ ở phía máy khách, chẳng hạn như nhà cung cấp dịch vụ xác thực bên thứ ba có chi phí khởi động quá cao.
- Dữ liệu cần thiết để một khung hiển thị tải phụ thuộc vào ngữ cảnh cụ thể chỉ ở phía máy khách, chẳng hạn như hiển thị các chế độ điều khiển cho một phần cứng được kết nối.
- Ứng dụng đủ nhỏ và đơn giản để kích thước cũng như độ phức tạp của ứng dụng không ảnh hưởng đến các nhược điểm nêu trên.
SPA có thể không phải là lựa chọn phù hợp về cấu trúc nếu:
- Hiệu suất tải ban đầu là cần thiết. Các SPA thường phải tải thêm JavaScript để xác định nội dung cần tải và cách hiển thị. Thời gian phân tích cú pháp và thực thi của JavaScript này kết hợp với truy xuất nội dung chậm hơn so với việc gửi HTML được kết xuất.
- Ứng dụng của bạn chủ yếu chạy trên các thiết bị có công suất từ thấp đến trung bình. Vì SPA phụ thuộc vào JavaScript để kết xuất, nên trải nghiệm người dùng phụ thuộc nhiều hơn đáng kể vào sức mạnh của thiết bị cụ thể so với ở MPA.
Vì SPA cần thay thế tính năng điều hướng tích hợp của trình duyệt bằng tính năng định tuyến, nên SPA yêu cầu mức độ phức tạp tối thiểu trong việc cập nhật hiệu quả chế độ xem hiện tại, quản lý các thay đổi điều hướng và dọn dẹp các chế độ xem trước đó mà trình duyệt xử lý, khiến chúng khó bảo trì hơn và tốn nhiều thuế hơn trên thiết bị của người dùng.
Ứng dụng nhiều trang
- Chủ yếu là cập nhật toàn trang.
- Tốc độ kết xuất ban đầu rất quan trọng.
- Tập lệnh phía máy khách có thể là một tính năng nâng cao.
- Chế độ xem phụ yêu cầu một lệnh gọi máy chủ khác.
- Ngữ cảnh không chuyển sang giữa các khung hiển thị.
- Yêu cầu máy chủ hoặc kết xuất trước.
Ứng dụng nhiều trang là một lựa chọn tốt về mặt cấu trúc nếu:
- Hoạt động tương tác của người dùng chủ yếu tập trung vào lượt xem một phần dữ liệu có dữ liệu dựa trên bối cảnh không bắt buộc, chẳng hạn như ứng dụng tin tức hoặc thương mại điện tử.
- Tốc độ kết xuất ban đầu rất quan trọng, vì việc gửi HTML đã kết xuất tới trình duyệt nhanh hơn so với việc gửi HTML đã kết xuất từ yêu cầu dữ liệu sau khi tải, phân tích cú pháp và thực thi một giải pháp thay thế dựa trên JavaScript.
- Khả năng tương tác hoặc ngữ cảnh phía máy khách có thể được đưa vào dưới dạng tính năng nâng cao sau lần tải đầu tiên, chẳng hạn như xếp lớp hồ sơ trên một trang được kết xuất hoặc thêm các thành phần phụ thuộc vào ngữ cảnh phía máy khách.
MPA có thể không phải là lựa chọn phù hợp về cấu trúc nếu:
- Việc tải xuống, phân tích lại và thực thi lại JavaScript hoặc CSS của bạn rất tốn kém. Nhược điểm này được giảm thiểu trong PWA bằng trình chạy dịch vụ.
- Ngữ cảnh phía máy khách (chẳng hạn như vị trí của người dùng) không được chuyển đổi liền mạch giữa các chế độ xem và việc thu thập lại ngữ cảnh đó có thể tốn kém. Bạn cần thu thập và truy xuất thông tin hoặc yêu cầu lại giữa các chế độ xem.
Bởi vì các chế độ xem riêng lẻ cần được máy chủ kết xuất động hoặc kết xuất trước trước khi truy cập, điều này có thể hạn chế việc lưu trữ hoặc thêm tính phức tạp của dữ liệu.
Nên chọn sản phẩm nào?
Ngay cả với những ưu và nhược điểm này, cả hai cấu trúc này đều hợp lệ để tạo PWA của bạn. Thậm chí, bạn có thể kết hợp các loại quảng cáo này cho các phần khác nhau trong ứng dụng, tuỳ thuộc vào nhu cầu của ứng dụng, chẳng hạn như thiết lập trang thông tin trên Cửa hàng Play theo cấu trúc MPA và quy trình thanh toán theo cấu trúc SPA.
Bất kể lựa chọn của bạn là gì, bước tiếp theo là tìm hiểu cách sử dụng nhân viên dịch vụ sao cho hiệu quả nhất nhằm mang lại trải nghiệm tốt nhất.
Sức mạnh của trình chạy dịch vụ
Trình chạy dịch vụ có rất nhiều quyền lực ngoài việc định tuyến và phân phối phản hồi được lưu vào bộ nhớ đệm và phản hồi từ mạng. Chúng tôi có thể tạo các thuật toán phức tạp để có thể cải thiện trải nghiệm và hiệu suất của người dùng.
Trình chạy dịch vụ bao gồm (SWI)
Một mẫu mới nổi để sử dụng trình chạy dịch vụ như một phần không thể thiếu trong cấu trúc trang web là trình chạy dịch vụ (SWI).
SWI chia các thành phần riêng lẻ, thường là một trang HTML, thành các phần dựa trên nhu cầu lưu vào bộ nhớ đệm, sau đó ghép chúng lại với nhau trong trình chạy dịch vụ để cải thiện tính nhất quán, hiệu suất và độ tin cậy, đồng thời giảm kích thước bộ nhớ đệm.
Hình ảnh này là trang web mẫu. Báo cáo này có năm phần khác nhau chia trang thành:
- Bố cục tổng thể.
- Tiêu đề chung (thanh tối ở trên cùng).
- Khu vực nội dung (đường ở giữa bên trái và hình ảnh).
- Thanh bên (thanh tối trung bình ở giữa bên phải).
- Chân trang (thanh dưới cùng tối).
Bố cục tổng thể
Bố cục tổng thể ít có khả năng thay đổi thường xuyên và không có phần phụ thuộc. Đây là lựa chọn phù hợp để giới thiệu trước.
Đầu trang và chân trang
Đầu trang và chân trang chung chứa các nội dung như trình đơn trên cùng và chân trang của trang web, đồng thời đưa ra một thách thức cụ thể: nếu toàn bộ trang được lưu vào bộ nhớ đệm, thì các yếu tố này có thể thay đổi giữa các lần tải trang, tuỳ thuộc vào thời điểm trang cụ thể được lưu vào bộ nhớ đệm.
Bằng cách tách chúng và lưu chúng vào bộ nhớ đệm độc lập với nội dung, bạn có thể đảm bảo rằng người dùng sẽ luôn nhận được cùng một phiên bản, bất kể thời điểm chúng được lưu vào bộ nhớ đệm. Vì không được cập nhật thường xuyên, nên các mẫu này cũng rất phù hợp để đề xuất trước. Tuy nhiên, các thành phần này có phần phụ thuộc: CSS và JavaScript của trang web.
CSS và JavaScript
Tốt nhất là bạn nên lưu CSS và JavaScript của trang web vào bộ nhớ đệm đã lỗi thời trong khi xác thực lại chiến lược để cho phép cập nhật dần mà không cần cập nhật trình chạy dịch vụ, như trong trường hợp của các nội dung được lưu trước vào bộ nhớ đệm. Tuy nhiên, các chú thích này cũng cần phải được giữ ở phiên bản tối thiểu bất cứ khi nào trình chạy dịch vụ cập nhật chú thích đầu trang hoặc chân trang chung mới. Do đó, bộ nhớ đệm của các thành phần này cũng phải được cập nhật với phiên bản mới nhất của thành phần khi trình chạy dịch vụ cài đặt.
Vùng nội dung
Tiếp theo là vùng nội dung. Tuỳ thuộc vào tần suất cập nhật, bạn nên chọn mạng trước hay cũ trong khi xác thực lại. Hình ảnh phải được lưu vào bộ nhớ đệm bằng chiến lược ưu tiên lưu vào bộ nhớ đệm, như đã thảo luận trước đó.
Thanh bên
Cuối cùng, giả sử nội dung thanh bên có chứa nội dung phụ như thẻ và các mục có liên quan thì nội dung này không đủ quan trọng để lấy từ mạng. Chiến lược này đã lỗi thời trong khi xác thực lại chiến lược.
Bây giờ, sau khi tìm hiểu tất cả những điều đó, bạn có thể nghĩ rằng mình chỉ có thể thực hiện kiểu lưu vào bộ nhớ đệm theo từng phần này cho các ứng dụng trang đơn. Tuy nhiên, bằng cách áp dụng các mẫu lấy cảm hứng từ phía cạnh bao gồm hoặc phía máy chủ được đưa vào trình chạy dịch vụ, với một số tính năng nâng cao của trình chạy dịch vụ, bạn có thể thực hiện việc này cho một trong hai cấu trúc.
Dùng thử
Bạn có thể dùng thử trình chạy dịch vụ trong lớp học lập trình tiếp theo:
Câu trả lời đồng thời
Bạn có thể tạo trang trước bằng mô hình giao diện ứng dụng trong thế giới SPA, nơi giao diện ứng dụng được lưu vào bộ nhớ đệm, sau đó được phân phát và nội dung được tải ở phía máy khách. Nhờ sự ra mắt và phạm vi cung cấp rộng rãi của Streams API, cả giao diện ứng dụng và nội dung đều có thể được kết hợp trong trình chạy dịch vụ và truyền trực tuyến đến trình duyệt, mang đến cho bạn khả năng lưu vào bộ nhớ đệm linh hoạt của giao diện ứng dụng với tốc độ của MPA.
Chrome làm điều này bởi vì:
- Luồng có thể được tạo không đồng bộ, cho phép nhiều phần của luồng đến từ các nguồn khác.
- Người yêu cầu luồng có thể bắt đầu xử lý phản hồi ngay khi có phần dữ liệu đầu tiên, thay vì đợi toàn bộ mục hoàn tất.
- Các trình phân tích cú pháp được tối ưu hoá cho quá trình phát trực tuyến, bao gồm cả trình duyệt, có thể dần dần hiển thị nội dung của luồng trước khi hoàn tất, tăng tốc hiệu suất phản hồi được cảm nhận.
Nhờ 3 thuộc tính này của luồng, các kiến trúc được xây dựng xung quanh tính năng phát trực tuyến thường có hiệu suất được cảm nhận nhanh hơn so với những kiến trúc không có.
Có thể khó làm việc với API luồng vì API này phức tạp và có cấp độ thấp. May mắn là có một mô-đun Hộp làm việc có thể giúp thiết lập phản hồi trực tuyến cho trình chạy dịch vụ của bạn.
Miền, nguồn gốc và phạm vi PWA
Trình chạy web, bao gồm cả trình chạy dịch vụ, bộ nhớ, thậm chí là cửa sổ của PWA đã cài đặt, đều chịu sự điều chỉnh của một trong những cơ chế bảo mật quan trọng nhất trên web: chính sách cùng nguồn gốc. Trong cùng một nguồn gốc, quyền sẽ được cấp, dữ liệu có thể được chia sẻ và trình chạy dịch vụ có thể giao tiếp với nhiều ứng dụng khách. Ngoài cùng một nguồn gốc, quyền không được cấp tự động và dữ liệu sẽ được tách riêng và không thể truy cập giữa các nguồn gốc khác nhau.
Chính sách cùng nguồn gốc
Hai URL được xác định là có nguồn gốc chính xác nếu giao thức, cổng và máy chủ lưu trữ giống nhau.
Ví dụ: https://squoosh.app và https://squoosh.app/v2 có cùng nguồn gốc, nhưng http://squoosh.app, https://squoosh.com, https://app.squoosh.app và https://squoosh.app:8080 có cùng nguồn gốc. Hãy xem tài liệu tham khảo MDN của chính sách cùng nguồn gốc để biết thêm thông tin và ví dụ.
Việc thay đổi miền con không phải là cách duy nhất mà một máy chủ lưu trữ có thể thay đổi. Mỗi máy chủ lưu trữ bao gồm một miền cấp cao nhất (TLD), một miền cấp phụ (SLD) và không có hoặc nhiều nhãn (đôi khi gọi là miền con), phân tách bằng dấu chấm ở giữa và đọc từ phải sang trái trong một URL. Thay đổi trong bất kỳ mục nào sẽ dẫn đến máy chủ lưu trữ khác.
Trong mô-đun quản lý cửa sổ, chúng ta đã thấy giao diện của trình duyệt trong ứng dụng khi người dùng chuyển đến một nguồn gốc khác từ một PWA đã cài đặt.
Trình duyệt trong ứng dụng đó sẽ xuất hiện ngay cả khi các trang web có cùng TLD và SLD, nhưng có nhãn khác nhau, vì sau đó chúng được coi là các nguồn gốc khác nhau.
Một trong những khía cạnh quan trọng của nguồn gốc trong ngữ cảnh duyệt web là cách hoạt động của bộ nhớ và các quyền. Một nguồn gốc có chung nhiều tính năng giữa tất cả nội dung và ứng dụng web tiến bộ (PWA) trong đó, bao gồm:
- Hạn mức bộ nhớ và dữ liệu (IndexedDB, cookie, bộ nhớ web, bộ nhớ đệm).
- Lượt đăng ký của trình chạy dịch vụ.
- Quyền được cấp hoặc bị từ chối (chẳng hạn như thông báo đẩy trên web, vị trí địa lý, cảm biến).
- Đăng ký đẩy web.
Khi bạn chuyển từ nguồn này sang nguồn gốc khác, tất cả quyền truy cập trước đó sẽ bị thu hồi. Do đó, bạn phải cấp lại các quyền và PWA của bạn không thể truy cập vào tất cả dữ liệu đã lưu trong bộ nhớ.