สถาปัตยกรรม

การออกแบบแอปพลิเคชันเพื่อใช้ประโยชน์จากเทคโนโลยีที่ทำให้ PWA นั้นเชื่อถือได้ ติดตั้งได้ และมีความสามารถเริ่มจากการทำความเข้าใจแอปพลิเคชันและข้อจำกัดของแอปพลิเคชัน จากนั้นจึงเลือกสถาปัตยกรรมที่เหมาะสมสำหรับทั้ง 2 แพลตฟอร์ม

SPA เทียบกับ MPA

ปัจจุบันการพัฒนาเว็บมีรูปแบบทางสถาปัตยกรรมหลัก 2 รูปแบบ ได้แก่ แอปแบบหน้าเดียวหรือ SPA และแอปแบบหลายหน้า หรือ MPA

แอปแบบหน้าเดียวกำหนดโดยให้ JavaScript ฝั่งไคลเอ็นต์ควบคุมการแสดงผล HTML ส่วนใหญ่หรือทั้งหมดของหน้าเว็บตามข้อมูลที่แอปดึงมาหรือจัดหาให้ แอปจะลบล้างการนำทางในตัวของเบราว์เซอร์ แล้วแทนที่ด้วยฟังก์ชันการจัดการเส้นทางและมุมมองของแอป

แอปแบบหลายหน้ามักจะมี HTML ที่แสดงผลล่วงหน้าซึ่งส่งไปยังเบราว์เซอร์โดยตรง ซึ่งมักปรับปรุงด้วย JavaScript ฝั่งไคลเอ็นต์หลังจากที่เบราว์เซอร์โหลด HTML เสร็จแล้ว และอาศัยกลไกการนำทางในตัวของเบราว์เซอร์เพื่อแสดงการดูที่ตามมา

ทั้ง 2 สถาปัตยกรรมใช้เพื่อสร้าง PWA ได้

แต่ละแบบก็มีทั้งข้อดีและข้อเสีย การเลือกรายการที่เหมาะสมกับกรณีการใช้งานและบริบทถือเป็นกุญแจสำคัญในการมอบประสบการณ์การใช้งานที่รวดเร็วและน่าเชื่อถือให้แก่ผู้ใช้

แอปหน้าเดียว

ข้อดี
  • ส่วนใหญ่เป็นการอัปเดตในหน้าเว็บแบบอะตอม
  • โหลดทรัพยากร Dependency ฝั่งไคลเอ็นต์เมื่อเริ่มต้นระบบ
  • การโหลดที่ตามมานั้นรวดเร็วเนื่องจากการใช้งานแคช
ข้อเสีย
  • ค่าใช้จ่ายในการโหลดครั้งแรกสูง
  • ประสิทธิภาพขึ้นอยู่กับฮาร์ดแวร์ของอุปกรณ์และการเชื่อมต่อเครือข่าย
  • จำเป็นต้องมีความซับซ้อนของแอปเพิ่มเติม

แอปหน้าเว็บเดียวเหมาะกับรูปแบบสถาปัตยกรรมที่ดีในกรณีต่อไปนี้

  • การโต้ตอบของผู้ใช้จะเน้นไปที่การอัปเดตระดับอะตอมของข้อมูลที่เชื่อมต่อถึงกันซึ่งแสดงในหน้าเดียวกันเป็นหลัก เช่น แดชบอร์ดข้อมูลแบบเรียลไทม์ หรือแอปตัดต่อวิดีโอ
  • แอปพลิเคชันของคุณมีทรัพยากร Dependency สำหรับการเริ่มต้นฝั่งไคลเอ็นต์เท่านั้น เช่น ผู้ให้บริการการตรวจสอบสิทธิ์บุคคลที่สามที่มีค่าใช้จ่ายในการเริ่มต้นใช้งานสูงต่ำ
  • ข้อมูลที่จำเป็นสำหรับมุมมองในการโหลดจะขึ้นอยู่กับบริบทเฉพาะฝั่งไคลเอ็นต์ ตัวอย่างเช่น การแสดงตัวควบคุมสำหรับฮาร์ดแวร์ที่เชื่อมต่อ
  • แอปมีขนาดเล็กและเรียบง่ายพอที่จะมีขนาดและความซับซ้อนที่ไม่กระทบต่อข้อเสียที่ระบุไว้ข้างต้น

SPA อาจไม่ใช่ตัวเลือกสถาปัตยกรรมที่ดีในกรณีต่อไปนี้

  • ประสิทธิภาพการโหลดเริ่มต้นเป็นสิ่งสำคัญ SPA จะต้องโหลด JavaScript มากขึ้นเพื่อกำหนดสิ่งที่จะโหลดและแสดงผล เวลาในการแยกวิเคราะห์และดำเนินการของ JavaScript นี้ รวมกับเนื้อหาที่ดึงมา จะช้ากว่าการส่ง HTML ที่แสดงผล
  • แอปของคุณทำงานส่วนใหญ่ในอุปกรณ์ที่ใช้พลังงานต่ำถึงค่าเฉลี่ย เนื่องจาก SPA ใช้ JavaScript ในการแสดงผล ประสบการณ์ของผู้ใช้จึงขึ้นอยู่กับพลังของอุปกรณ์แต่ละเครื่องมากกว่าจาก MPA อย่างมาก

เนื่องจาก SPA จำเป็นต้องแทนที่การนำทางในตัวของเบราว์เซอร์ด้วยการกำหนดเส้นทาง SPA จึงต้องมีความซับซ้อนขั้นต่ำในการอัปเดตมุมมองปัจจุบันอย่างมีประสิทธิภาพ การจัดการการเปลี่ยนแปลงการนำทาง และการล้างมุมมองก่อนหน้าที่เบราว์เซอร์จะจัดการ ทำให้การดูแลรักษาโดยรวมยากขึ้นและทำให้ผู้ใช้เสียภาษีมากขึ้น

แอปแบบหลายหน้า

ข้อดี
  • ส่วนใหญ่เป็นการอัปเดตทั้งหน้า
  • ความเร็วในการแสดงผลเริ่มต้นเป็นสิ่งสำคัญ
  • การเขียนสคริปต์ฝั่งไคลเอ็นต์อาจเป็นการเพิ่มประสิทธิภาพได้
ข้อเสีย
  • มุมมองรองต้องมีการเรียกจากเซิร์ฟเวอร์อีกครั้ง
  • บริบทจะไม่ยกมาคั่นระหว่างการดู
  • ต้องใช้เซิร์ฟเวอร์หรือการแสดงผลล่วงหน้า

แอปแบบหลายหน้าเป็นทางเลือกทางสถาปัตยกรรมที่ดีในกรณีต่อไปนี้

  • การโต้ตอบของผู้ใช้จะเน้นไปที่มุมมองข้อมูลชิ้นเดียวที่มีข้อมูลตามบริบทที่เป็นตัวเลือกเป็นหลัก เช่น แอปข่าวหรือแอปอีคอมเมิร์ซ
  • ความเร็วในการแสดงผลเริ่มต้นเป็นสิ่งสำคัญ เนื่องจากการส่ง HTML ที่แสดงผลแล้วไปยังเบราว์เซอร์นั้นรวดเร็วกว่าการรวมข้อมูลจากคำขอข้อมูลหลังจากการโหลด แยกวิเคราะห์ และดำเนินการกับทางเลือกที่ใช้ JavaScript
  • การโต้ตอบหรือบริบทฝั่งไคลเอ็นต์อาจรวมอยู่ในการเพิ่มประสิทธิภาพหลังจากการโหลดครั้งแรกได้ เช่น การวางโปรไฟล์ลงในหน้าที่แสดงผลหรือเพิ่มคอมโพเนนต์รองที่ขึ้นอยู่กับบริบทฝั่งไคลเอ็นต์

MPA อาจไม่ใช่ตัวเลือกด้านสถาปัตยกรรมที่ดีในกรณีต่อไปนี้

  • การดาวน์โหลด การแยกวิเคราะห์ใหม่ และการนำ JavaScript หรือ CSS ไปใช้งานซ้ำนั้นมีค่าใช้จ่ายสูง ปัญหานี้จะลดลงใน PWA ด้วย Service Worker
  • บริบทฝั่งไคลเอ็นต์ เช่น ตำแหน่งของผู้ใช้ ไม่ได้ส่งต่อระหว่างการดูได้อย่างราบรื่น และการได้รับบริบทนั้นอีกครั้งอาจมีค่าใช้จ่ายสูง ซึ่งจำเป็นต้องมีการบันทึกและดึงข้อมูลหรือขออีกครั้งระหว่างข้อมูลพร็อพเพอร์ตี้

เนื่องจากข้อมูลพร็อพเพอร์ตี้แต่ละรายการจะต้องแสดงผลแบบไดนามิกโดยเซิร์ฟเวอร์หรือการแสดงผลล่วงหน้าก่อนการเข้าถึง ซึ่งอาจจำกัดโฮสติ้งหรือเพิ่มความซับซ้อนของข้อมูล

คุณควรเลือกตัวเลือกใด

ถึงจะมีข้อดีและข้อเสียเหล่านี้ สถาปัตยกรรมทั้ง 2 แบบก็ใช้ได้สำหรับการสร้าง PWA อีกทั้งยังผสมผสานให้เข้ากับส่วนต่างๆ ของแอปได้ตามความต้องการ เช่น การทำให้ข้อมูลผลิตภัณฑ์ใน Store ใช้สถาปัตยกรรม MPA และขั้นตอนการชำระเงินเป็นไปตามสถาปัตยกรรม SPA

ไม่ว่าจะเลือกตัวเลือกใด ขั้นตอนต่อไปคือการทำความเข้าใจวิธีใช้ Service Worker ให้ดีที่สุดเพื่อมอบประสบการณ์ที่ดีที่สุด

ศักยภาพของ Service Worker

โปรแกรมทำงานของบริการมีประสิทธิภาพสูงกว่าการกำหนดเส้นทางพื้นฐาน และการนำส่งการตอบกลับที่แคชไว้และเครือข่าย เราสามารถสร้างอัลกอริทึมที่ซับซ้อนซึ่งสามารถปรับปรุงประสบการณ์และประสิทธิภาพของผู้ใช้ได้

โปรแกรมทำงานของบริการรวมถึง (SWI)

รูปแบบใหม่ๆ ในการใช้ Service Worker เป็นส่วนหนึ่งของสถาปัตยกรรมของเว็บไซต์ก็คือ Service Worker นั้นรวมถึง (SWI) ด้วย SWI แบ่งเนื้อหาแต่ละรายการซึ่งมักจะเป็นหน้า HTML ออกเป็นส่วนๆ ตามความต้องการการแคช จากนั้นประกอบเนื้อหาเหล่านั้นกลับเข้าไปใน Service Worker เพื่อปรับปรุงความสอดคล้อง ประสิทธิภาพ และความน่าเชื่อถือ พร้อมลดขนาดแคช เว็บไซต์ที่มีส่วนหัวร่วม พื้นที่เนื้อหา แถบด้านข้าง และส่วนท้าย

รูปภาพนี้เป็นหน้าเว็บตัวอย่าง ซึ่งประกอบด้วย 5 ส่วนซึ่งแบ่งหน้าออกเป็น

  • เลย์เอาต์โดยรวม
  • ส่วนหัวส่วนกลาง (แถบสีเข้มด้านบน)
  • พื้นที่เนื้อหา (เส้นกลางซ้ายและรูปภาพ)
  • แถบด้านข้าง (แถบสูงปานกลางสีเข้มด้านขวา)
  • ส่วนท้าย (แถบด้านล่างสีเข้ม)

เลย์เอาต์โดยรวม

เลย์เอาต์โดยรวมมีแนวโน้มที่จะไม่เปลี่ยนแปลงบ่อยและไม่มีทรัพยากร Dependency ซึ่งเหมาะสำหรับการแคชล่วงหน้า

ส่วนหัวและส่วนท้ายร่วมประกอบด้วยข้อมูลต่างๆ เช่น เมนูด้านบนและส่วนท้ายของเว็บไซต์ ซึ่งส่งผลให้เกิดปัญหาที่เฉพาะเจาะจง กล่าวคือ หากระบบแคชหน้าทั้งหน้า หน้าอาจเปลี่ยนไประหว่างการโหลดหน้าเว็บ ทั้งนี้ขึ้นอยู่กับเวลาที่แคชหน้าเว็บนั้นๆ

การแยกและแคชแยกต่างหากของเนื้อหาช่วยให้คุณมั่นใจได้ว่าผู้ใช้จะได้รับเวอร์ชันเดียวกันเสมอ ไม่ว่าผู้ใช้จะแคชตอนใดก็ตาม เนื่องจากมีการอัปเดตไม่บ่อยนัก จึงเป็นตัวเลือกที่เหมาะสำหรับการแคชล่วงหน้าเช่นกัน แต่จะขึ้นอยู่กับ CSS และ JavaScript ของเว็บไซต์

CSS และ JavaScript

ตามหลักการแล้ว คุณควรแคช CSS และ JavaScript ของเว็บไซต์โดยไม่มีอัปเดตขณะตรวจสอบกลยุทธ์อีกครั้งเพื่ออนุญาตให้มีการอัปเดตเพิ่มเติมโดยไม่ต้องอัปเดตโปรแกรมทำงานของบริการ เนื่องจากเป็นกรณีที่มีชิ้นงานที่แคชไว้ล่วงหน้า อย่างไรก็ตาม ต้องเก็บไว้ที่เวอร์ชันขั้นต่ำเมื่อ Service Worker อัปเดตโดยใช้ส่วนหัวหรือส่วนท้ายร่วมใหม่ ด้วยเหตุนี้ จึงควรอัปเดตแคชด้วยเนื้อหาเวอร์ชันล่าสุดเมื่อ Service Worker ติดตั้ง

พื้นที่เนื้อหา

ถัดไปคือส่วนเนื้อหา การใช้เครือข่ายแรกหรือไม่มีการอัปเดตขณะที่ตรวจสอบความถูกต้องอีกครั้งถือเป็นกลยุทธ์ที่ดี ทั้งนี้ขึ้นอยู่กับความถี่ในการอัปเดต ควรแคชรูปภาพด้วยกลยุทธ์ "Cache First" ตามที่ได้พูดคุยกันไว้ก่อนหน้านี้

สุดท้าย การสันนิษฐานว่าที่แถบด้านข้างมีเนื้อหารอง เช่น แท็กและรายการที่เกี่ยวข้อง ไม่จำเป็นต้องดึงข้อมูลจากเครือข่าย ไม่มีอัปเดต แต่การตรวจสอบกลยุทธ์อีกครั้งใช้ได้ผลกับสถานการณ์นี้

หลังจากที่ดูไปแล้ว คุณอาจคิดว่าสามารถแคชเนื้อหาเหล่านี้ได้เฉพาะสำหรับแอปหน้าเว็บเดียว แต่เมื่อใช้รูปแบบที่ได้รับแรงบันดาลใจจาก EDGE Side หรือคำสั่งรวมฝั่งเซิร์ฟเวอร์ใน Service Worker กับฟีเจอร์ขั้นสูงบางส่วนของ Service Worker คุณจะทำได้ในสถาปัตยกรรมทั้งสองแบบ

ลองดูเอง

คุณลองใช้ Service Worker ที่มาพร้อมกับ Codelab ถัดไปได้

การตอบกลับสตรีมมิง

คุณสามารถสร้างหน้าก่อนหน้าได้โดยใช้รูปแบบ App Shell ในโลก SPA ซึ่งจะมีการแคช App Shell แล้วแสดงผล และโหลดเนื้อหาในฝั่งไคลเอ็นต์ ด้วยการเปิดตัวและความพร้อมใช้งานมากมายของ Streams API ทั้ง App Shell และเนื้อหาสามารถรวมกันใน Service Worker และสตรีมไปยังเบราว์เซอร์ ทำให้การแคชของ App Shell มีความยืดหยุ่นด้วยความเร็วแบบ MPA

ซึ่งเกิดจากสาเหตุต่อไปนี้

  • คุณสามารถสร้างสตรีมแบบไม่พร้อมกัน ทำให้ส่วนต่างๆ ของสตรีมมาจากแหล่งอื่นได้
  • ผู้ขอสตรีมสามารถเริ่มตอบกลับได้ทันทีที่ข้อมูลกลุ่มแรกพร้อมใช้งาน แทนที่จะต้องรอให้สินค้าทั้งหมดเสร็จสมบูรณ์
  • โปรแกรมแยกวิเคราะห์ที่เพิ่มประสิทธิภาพสำหรับการสตรีมรวมถึงเบราว์เซอร์สามารถแสดงเนื้อหาของสตรีมอย่างต่อเนื่องก่อนที่จะเสร็จสมบูรณ์ ซึ่งช่วยเร่งประสิทธิภาพของการตอบสนองที่รับรู้ได้

ด้วยคุณสมบัติทั้ง 3 ของสตรีมนี้ สถาปัตยกรรมที่สร้างขึ้นจากการสตรีมมักมีประสิทธิภาพที่เร็วกว่าที่รับรู้ไม่ได้

การใช้งาน Streams API อาจท้าทายเนื่องจากมีความซับซ้อนและอยู่ในระดับต่ำ โชคดีที่มีโมดูล Workbox ที่ช่วยตั้งค่าการตอบสนองการสตรีมสำหรับ Service Worker ของคุณได้

โดเมน ต้นทาง และขอบเขต PWA

Web Worker ซึ่งรวมถึง Service Worker, พื้นที่เก็บข้อมูล รวมถึงหน้าต่างของ PWA ที่ติดตั้งไว้ทั้งหมดจะอยู่ภายใต้กลไกการรักษาความปลอดภัยที่สำคัญที่สุดบนเว็บ ซึ่งก็คือนโยบายต้นทางเดียวกัน ภายในต้นทางเดียวกัน ระบบจะให้สิทธิ์ แชร์ข้อมูลได้ และ Service Worker พูดคุยกับไคลเอ็นต์ต่างๆ ได้ เมื่ออยู่นอกต้นทางเดียวกัน ระบบจะไม่ให้สิทธิ์โดยอัตโนมัติ และจะแยกข้อมูลและเข้าถึงไม่ได้ระหว่างต้นทางที่ต่างกัน

นโยบายต้นทางเดียวกัน

URL 2 รายการจะได้รับการระบุว่ามีต้นทางที่แน่ชัดหากโปรโตคอล พอร์ต และโฮสต์เหมือนกัน

เช่น https://squoosh.app และ https://squoosh.app/v2 มีต้นทางเดียวกัน แต่ http://squoosh.app, https://squoosh.com, https://app.squoosh.app และ https://squoosh.app:8080 อยู่ในต้นทางที่ต่างกัน ดูข้อมูลเพิ่มเติมและตัวอย่างได้ที่การอ้างอิง MDN ของนโยบายต้นทางเดียวกัน

การเปลี่ยนโดเมนย่อยไม่ใช่ทางเดียวที่โฮสต์จะเปลี่ยนแปลงได้ โฮสต์แต่ละรายการประกอบด้วยโดเมนระดับบนสุด (TLD) โดเมนระดับรอง (SLD) และป้ายกำกับอย่างน้อย 0 รายการ (บางครั้งเรียกว่าโดเมนย่อย) คั่นด้วยจุดระหว่างข้อความและอ่านจากขวาไปซ้ายใน URL การเปลี่ยนแปลงรายการใดก็ตามจะทําให้เกิดโฮสต์อื่น

ในโมดูลการจัดการหน้าต่าง เราได้เห็นหน้าตาของเบราว์เซอร์ในแอปเมื่อผู้ใช้ไปยังต้นทางอื่นที่ไม่ใช่ PWA ที่ติดตั้งแล้ว

เบราว์เซอร์ในแอปดังกล่าวจะปรากฏแม้ว่าเว็บไซต์จะมี TLD และ SLD เหมือนกัน แต่มีป้ายกำกับต่างกัน เนื่องจากถือว่ามีต้นทางที่ต่างกัน

หนึ่งในแง่มุมสําคัญของต้นทางในบริบทการท่องเว็บคือวิธีการทำงานของพื้นที่เก็บข้อมูลและสิทธิ์ ต้นทาง 1 แห่งจะแชร์ฟีเจอร์มากมายในเนื้อหาและ PWA ทั้งหมดภายในต้นทาง ซึ่งได้แก่

  • โควต้าพื้นที่เก็บข้อมูลและข้อมูล (IndexedDB, คุกกี้, พื้นที่เก็บข้อมูลบนเว็บ, พื้นที่เก็บข้อมูลแคช)
  • การลงทะเบียน Service Worker
  • สิทธิ์ที่ได้รับหรือปฏิเสธ (เช่น พุชจากเว็บ ตำแหน่งทางภูมิศาสตร์ เซ็นเซอร์)
  • การลงทะเบียนพุชจากเว็บ

เมื่อคุณย้ายจากต้นทางหนึ่งไปยังอีกต้นทางหนึ่ง การเข้าถึงก่อนหน้านี้ทั้งหมดจะถูกเพิกถอน ดังนั้นจึงต้องให้สิทธิ์อีกครั้ง และ PWA จะเข้าถึงข้อมูลทั้งหมดที่บันทึกไว้ในพื้นที่เก็บข้อมูลไม่ได้

แหล่งข้อมูล