โปรแกรมทำงานของบริการและ Cache Storage API

Jeff Posnick

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

แต่โชคดีที่เรามีเครื่องมือใหม่ 2 อย่างที่ช่วยพลิกสถานการณ์ให้ดีขึ้นได้ ซึ่งได้แก่ Service Worker และ Cache Storage API เนื่องจากมีการใช้ร่วมกันบ่อยครั้ง คุณจึงควรเรียนรู้เกี่ยวกับทั้ง 2 รายการพร้อมกัน

Service Worker

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

เวิร์กเกอร์บริการมีความสามารถพิเศษบางอย่าง นอกเหนือจากหน้าที่อื่นๆ แล้ว เครื่องมือนี้จะรออย่างอดทนเพื่อให้เว็บแอปของคุณส่งคำขอขาออก จากนั้นจะดําเนินการโดยขัดขวางคำขอ การดำเนินการที่ Service Worker จะทำกับคำขอที่ขัดจังหวะนี้ขึ้นอยู่กับคุณ

สําหรับคําขอบางรายการ แนวทางปฏิบัติที่ดีที่สุดอาจเป็นเพียงการอนุญาตให้คําขอไปยังเครือข่ายต่อ เช่นเดียวกับสิ่งที่จะเกิดขึ้นหากไม่มี Service Worker เลย

แต่สำหรับคำขออื่นๆ คุณสามารถใช้สิ่งที่ยืดหยุ่นกว่าแคช HTTP ของเบราว์เซอร์ และแสดงการตอบกลับที่รวดเร็วและเชื่อถือได้โดยไม่ต้องกังวลเกี่ยวกับเครือข่าย ซึ่งต้องใช้อีกชิ้นหนึ่งของปริศนาอย่าง Cache Storage API

Cache Storage API

Cache Storage API เปิดโอกาสใหม่ๆ มากมายให้กับนักพัฒนาแอป โดยให้สิทธิ์ควบคุมเนื้อหาในแคชได้อย่างเต็มที่ Cache Storage API ใช้แนวทางการแคชที่ขับเคลื่อนโดยโค้ดแทนที่จะใช้ส่วนหัว HTTP ร่วมกับฮิวริสติกในตัวของเบราว์เซอร์ Cache Storage API จะมีประโยชน์อย่างยิ่งเมื่อเรียกใช้จาก JavaScript ของ Service Worker

เดี๋ยวก่อน… มีแคชอีกรายการที่ต้องคำนึงถึงไหม

คุณอาจถามตัวเองว่า "ฉันยังต้องกำหนดค่าส่วนหัว HTTP อยู่ไหม" และ "ฉันจะทําอะไรได้บ้างกับแคชใหม่นี้ที่ทําไม่ได้กับแคช HTTP" ไม่ต้องกังวล อาการเหล่านี้เป็นปฏิกิริยาตามปกติ

เรายังคงแนะนำให้คุณกำหนดค่าส่วนหัว Cache-Control ในเว็บเซิร์ฟเวอร์ แม้ว่าคุณจะรู้ว่าใช้ Cache Storage API อยู่ก็ตาม โดยปกติแล้ว คุณอาจตั้งค่า Cache-Control: no-cache สำหรับ URL ที่ไม่มีเวอร์ชัน และ/หรือ Cache-Control: max-age=31536000 สำหรับ URL ที่มีข้อมูลเวอร์ชัน เช่น แฮช

เมื่อป้อนข้อมูลแคชของ Cache Storage API เบราว์เซอร์จะตรวจสอบรายการที่มีอยู่โดยค่าเริ่มต้นในแคช HTTP และใช้รายการเหล่านั้นหากพบ หากคุณเพิ่ม URL ที่มีเวอร์ชันลงในแคชของ Cache Storage API เบราว์เซอร์จะหลีกเลี่ยงคำขอเครือข่ายเพิ่มเติม อีกด้านหนึ่งคือ หากคุณใช้ส่วนหัว Cache-Control ที่กําหนดค่าไม่ถูกต้อง เช่น ระบุอายุแคชที่ยาวนานสําหรับ URL ที่ไม่มีเวอร์ชัน คุณอาจทําให้สถานการณ์แย่ลงด้วยการเพิ่มเนื้อหาที่ล้าสมัยนั้นลงใน Cache Storage API การจัดเรียงลักษณะการทำงานของแคช HTTP เป็นข้อกําหนดเบื้องต้นในการใช้ Cache Storage API อย่างมีประสิทธิภาพ

สิ่งที่ทำได้ด้วย API ใหม่นี้นั้นมีมากมาย การใช้งานทั่วไปบางอย่างที่อาจทำได้ยากหรือเป็นไปไม่ได้หากมีเพียงแคช HTTP ได้แก่

• ใช้แนวทาง "รีเฟรชในเบื้องหลัง" สำหรับเนื้อหาที่แคชไว้ ซึ่งเรียกว่า "stale-while-revalidate"
• จำกัดจำนวนชิ้นงานสูงสุดที่จะแคช และใช้นโยบายการหมดอายุที่กำหนดเองเพื่อนำรายการออกเมื่อถึงขีดจำกัดนั้น
• เปรียบเทียบการตอบสนองของเครือข่ายที่แคชไว้ก่อนหน้านี้กับการตอบสนองใหม่เพื่อดูว่ามีการเปลี่ยนแปลงหรือไม่ และอนุญาตให้ผู้ใช้อัปเดตเนื้อหา (เช่น ด้วยปุ่ม) เมื่อมีการอัปเดตข้อมูลจริงๆ

ดูข้อมูลเพิ่มเติมได้ที่Cache API: คู่มือฉบับย่อ

ข้อมูลเบื้องต้นเกี่ยวกับ API

สิ่งที่ควรคำนึงถึงเกี่ยวกับการออกแบบ API มีดังนี้

• ระบบจะใช้ออบเจ็กต์ Request เป็นคีย์ที่ไม่ซ้ำกันเมื่ออ่านและเขียนลงในแคชเหล่านี้ เพื่อความสะดวก คุณสามารถส่งสตริง URL เช่น 'https://example.com/index.html' เป็นคีย์แทนออบเจ็กต์ Request จริง และ API จะจัดการให้คุณโดยอัตโนมัติ
• Response ออบเจ็กต์เป็นค่าในแคชเหล่านี้
• ระบบจะไม่สนใจส่วนหัว Cache-Control ใน Response หนึ่งๆ เมื่อแคชข้อมูล ไม่มีการตรวจสอบวันหมดอายุหรือความใหม่ในตัวโดยอัตโนมัติ และเมื่อคุณจัดเก็บรายการไว้ในแคช รายการนั้นจะยังคงอยู่จนกว่าโค้ดของคุณจะนำออกอย่างชัดเจน (มีไลบรารีที่ลดความซับซ้อนในการดูแลรักษาแคชในนามของคุณ เราจะอธิบายในภายหลังในชุดบทแนะนำนี้)
• ซึ่งแตกต่างจาก API แบบซิงค์รุ่นเก่า เช่น LocalStorage ตรงที่การดำเนินการทั้งหมดของ Cache Storage API เป็นแบบไม่ซิงค์

ข้อมูลเบื้องต้น: Promise และ async/await

Service Worker และ Cache Storage API ใช้แนวคิดการเขียนโปรแกรมแบบแอซิงโครนัส โดยเฉพาะอย่างยิ่ง พวกมันใช้ Promise อย่างมากเพื่อแสดงผลลัพธ์ในอนาคตของการดำเนินการแบบแอสซิงค์ คุณควรทำความคุ้นเคยกับสัญญาและไวยากรณ์ async/await ที่เกี่ยวข้องก่อนลงมือใช้งาน

อย่าเพิ่งทําให้โค้ดใช้งานได้

แม้ว่าจะสร้างรากฐานที่สำคัญและใช้งานได้ตามที่เป็น แต่ทั้ง Service Worker และ Cache Storage API ก็เป็นองค์ประกอบพื้นฐานระดับล่างที่มีประสิทธิภาพ โดยมีกรณีขอบเขตและ "ข้อควรระวัง" อยู่จำนวนหนึ่ง มีเครื่องมือระดับสูงขึ้นบางรายการที่จะช่วยให้ใช้งาน API เหล่านั้นได้ง่ายขึ้น และให้คุณมีทุกอย่างที่จําเป็นในการสร้าง Service Worker ที่พร้อมใช้งานจริง คู่มือถัดไปจะกล่าวถึงเครื่องมือดังกล่าวอย่างWorkbox