Cấu trúc

Khi thiết kế ứng dụng sao cho khai thác tối đa công nghệ giúp PWA đáng tin cậy, có thể cài đặt và có khả năng hoạt động, hãy bắt đầu từ việc hiểu ứng dụng và các hạn chế của ứng dụng, sau đó chọn kiến trúc phù hợp cho cả hai.

SPA so với MPA

Hiện nay, có hai mẫu cấu 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 (hay MPA).

Ứng dụng trang đơn được xác định bằng cách cho phép ứng dụng kiểm soát hầu hết hoặc tất cả hoạt động 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 này ghi đè tính năng điều hướng tích hợp của trình duyệt, thay thế chức năng này bằng chức năng định tuyến và xử lý khung hiển thị.

Các ứng dụng nhiều trang thường có HTML được kết xuất trước được gửi 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 của trình duyệt để hiển thị các chế độ xem tiếp theo.

Bạn có thể dùng cả hai cấu trúc này để tạo PWA.

Mỗi phương thức đều có ưu và nhược điểm riêng. Do đó, việc chọn một công 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 để mang đến trải nghiệm nhanh chóng và đáng tin cậy cho người dùng.

Ứng dụng trang đơn

Ưu điểm
  • Chủ yếu là các bản cập nhật không thể phân chia trong trang.
  • 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 bộ nhớ đệm đã được sử dụng.
Nhược điể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 bắt buộc phải có độ phức tạp cao hơn.

Ứng dụng trang đơn phù hợp 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 việc cập nhật không thể phân chia cho dữ liệu liên kết được hiển thị trên cùng một trang, chẳng hạn như trang tổng quan về 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 chạy chỉ ở phía máy khách, chẳng hạn như một trì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 để tải một khung hiển thị 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 đã kết nối.
  • Ứng dụng đủ nhỏ và đơn giản để kích thước và độ phức tạp của ứng dụng không ảnh hưởng đến những nhược điểm nêu trên.

SPA có thể không phải là một lựa chọn cấu trúc tốt nếu:

  • Hiệu suất tải ban đầu rất cần thiết. SPA thường cần phải tải thêm JavaScript để xác định nội dung cần tải và cách hiển thị nội dung đó. 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 việc truy xuất nội dung) chậm hơn so với việc gửi HTML đã 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 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 vào sức mạnh của thiết bị cụ thể hơn nhiều so với trong 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à xoá các chế độ xem trước đó mà trình duyệt sẽ xử lý, khiến việc bảo trì tổng thể trở nên khó khăn hơn và nhiều thuế hơn trên thiết bị của người dùng.

Ứng dụng nhiều trang

Ưu điểm
  • Chủ yếu là nội dung 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à tính năng nâng cao.
Nhược điểm
  • Khung hiển thị phụ yêu cầu một lệnh gọi máy chủ khác.
  • Ngữ cảnh không chuyển qua lại 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 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 chế độ xem của một phần dữ liệu duy nhất với dữ liệu dựa trên bối cảnh tuỳ chọn, ví dụ 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 cho trình duyệt sẽ nhanh hơn so với tập hợp HTML từ yêu cầu dữ liệu sau khi tải, phân tích cú pháp và thực thi giải pháp thay thế dựa trên JavaScript.
  • Ngữ cảnh hoặc tính tương tác 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 một hồ sơ lên một trang đã kết xuất hoặc thêm các thành phần phụ phụ thuộc vào ngữ cảnh phía máy khách.

MPA có thể không phải là một lựa chọn tốt về cấu trúc nếu:

  • Việc tải xuống lại, phân tích cú pháp lại và thực thi lại JavaScript hoặc CSS sẽ rất tốn kém. Nhược điểm này được giảm thiểu trong PWA cùng với trình chạy dịch vụ.
  • Ngữ cảnh phía máy khách (chẳng hạn như thông tin vị trí của người dùng) không thể chuyển đổi liền mạch giữa các khung hiển thị. Do đó, việc thu thập lại ngữ cảnh đó có thể sẽ gây tốn kém. Bạn cần chụp và truy xuất thành phần hiển thị này hoặc yêu cầu lại kết quả giữa các lượt xem.

Bởi vì từng khung hiển thị cần được máy chủ kết xuất một cách linh động hoặc đượ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 làm tăng độ phức tạp của dữ liệu.

Chọn sản phẩm nào?

Ngay cả khi có các ưu và nhược điểm này, cả hai cấu trúc này đều hợp lệ để tạo PWA. Bạn thậm chí có thể kết hợp những thành phần này cho nhiều phần trong ứng dụng, tuỳ theo nhu cầu của ứng dụng, chẳng hạn như trang thông tin trên Cửa hàng Play tuân theo cấu trúc MPA và quy trình thanh toán tuân theo cấu trúc SPA.

Bất kể lựa chọn nào, bước tiếp theo là tìm hiểu cách sử dụng nhân viên hỗ trợ dịch vụ một cách hiệu quả nhất để mang lại trải nghiệm tốt nhất.

Sức mạnh của trình chạy dịch vụ

Service worker có rất nhiều quyền lực ngoài việc định tuyến và phân phối cơ bản các phản hồi được lưu vào bộ nhớ đệm và phản hồi mạng. Chúng tôi có thể tạo các thuật toán phức tạp nhằm 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 hình mẫu mới nổi cho việc 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 của một 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. Một trang web có tiêu đề chung, vùng nội dung, thanh bên và chân trang.

Hình ảnh này là trang web mẫu. Trang 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).
  • Vùng nội dung (hình ảnh và dòng ở giữa bên trái).
  • Thanh bên (thanh cao, 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ể có thể không thay đổi thường xuyên và không có phần phụ thuộc. Đó là một ứng viên phù hợp để lưu trước.

Đầ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 đặt ra một thách thức cụ thể: nếu toàn bộ trang được lưu vào bộ nhớ đệm, thì những 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 nhất định được lưu vào bộ nhớ đệm.

Bằng cách tách riêng và lưu chúng vào bộ nhớ đệm một cách độ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 bạn cũng có thể tìm kiếm dữ liệu này trước khi cần. 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à nên lưu CSS và JavaScript của trang web vào bộ nhớ đệm cũ 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ụ, vì trường hợp này xảy ra với các nội dung được lưu vào bộ nhớ đệm. Tuy nhiên, chúng cũng cần được duy trì ở phiên bản tối thiểu mỗi khi trình chạy dịch vụ cập nhật đầu trang hoặc chân trang chung mới. Do đó, bộ nhớ đệm của trình chạy dịch vụ cũng phải được cập nhật phiên bản thành phần mới nhất khi trình chạy dịch vụ này 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, dù là mạng nào thì trước tiên hay mạng cũ trong khi xác thực lại là một chiến lược phù hợp. Hình ảnh nên đượ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 đó.

Cuối cùng, giả sử nội dung thanh bên chứa nội dung phụ như thẻ và các mục có liên quan, nội dung này sẽ 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 thông tin đó, bạn có thể nghĩ rằng mình chỉ có thể lưu vào bộ nhớ đệm trên mỗi 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ừ bao gồm cạnh viền hoặc bao gồm phía máy chủ trong 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.

Thử ngay

Bạn có thể dùng thử Service worker bao gồm trong lớp học lập trình tiếp theo:

Hiện câu trả lời theo thời gian thực

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 áp dụng 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 đế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 shell ứng dụng với tốc độ của MPA.

Trang web thực hiện điều này bởi vì:

  • Luồng có thể được xây dựng không đồng bộ, cho phép các phần khác nhau 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 phần dữ liệu đầu tiên có sẵ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 luồng 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, nhờ đó tăng tốc hiệu suất cảm nhận được của phản hồi.

Nhờ có 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 các kiến trúc không có hiệu suất như vậy.

Việc xử lý API Luồng có thể không hề dễ dàng vì đây là API phức tạp và có cấp độ thấp. May mắn là có một mô-đun Workbox có thể giúp thiết lập phản hồi truyền 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 của PWA

Nhân viên web, bao gồm cả trình chạy dịch vụ, bộ nhớ, ngay cả 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, các quyền sẽ được cấp, dữ liệu có thể được chia sẻ và worker có thể giao tiếp với nhiều ứng dụng khách. Bên ngoài cùng một nguồn gốc, các quyền sẽ không tự động được cấp và dữ liệu sẽ bị tách biệt và không thể truy cập được giữa nhiều nguồn gốc.

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.apphttps://squoosh.app/v2 có cùng nguồn gốc nhưng http://squoosh.app, https://squoosh.com, https://app.squoosh.apphttps://squoosh.app:8080 có cùng nguồn gốc. Hãy xem tài liệu tham khảo về MDN của chính sách cùng nguồn gốc để biết thêm thông tin và ví dụ.

Thay đổi miền con không phải là cách duy nhất mà máy chủ lưu trữ có thể thay đổi. Mỗi máy chủ lưu trữ được tạo thành từ một miền cấp cao nhất (TLD), một miền cấp phụ (SLD) và không hoặc nhiều nhãn (đôi khi còn gọi là miền con), được phân tách bằng các dấu chấm ở giữa và được đọc từ phải sang trái trong một URL. Thay đổi trong bất kỳ mục nào cũng dẫn đến một 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 với một ứng dụng web tiến bộ (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 với 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 trong số tất cả nội dung và ứng dụng web tiến bộ (PWA) có trong đó, bao gồm:

  • Hạn mức bộ nhớ và dữ liệu (IndexedDB, cookie, bộ nhớ web, bộ nhớ đệm).
  • Đăng ký 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, định vị vị trí, cảm biến).
  • Đăng ký đẩy trên web.

Khi bạn di 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. Vì vậy, các quyền sẽ phải được cấp lại và PWA không thể truy cập vào tất cả dữ liệu đã lưu trong bộ nhớ.

Tài nguyên