קובצי שירות (service worker) ו-Cache Storage API

Jeff Posnick

אתם נאבקים כדי להשיג אמינות ברשת. מטמון ה-HTTP של הדפדפן הוא קו ההגנה הראשון, אבל כמו שלמדתם, הוא יעיל רק כשאתם טוענים כתובות URL עם גרסאות שכבר ביקרתם בהן. מטמון ה-HTTP לבדו לא מספיק.

למרבה המזל, יש שני כלים חדשים יותר שיכולים לעזור לכם להטות את הכף לטובתכם: service workers ו-Cache Storage API. בגלל שמשתמשים בהם ביחד לעיתים קרובות, כדאי ללמוד על שניהם בו-זמנית.

קובצי שירות (service worker)

Service worker מובנה בדפדפן ונשלט על ידי קוד JavaScript נוסף שאתם צריכים ליצור. אתם פורסים את הקובץ הזה לצד הקבצים האחרים שמרכיבים את אפליקציית האינטרנט שלכם.

ל-Service Worker יש כמה יכולות מיוחדות. בין שאר התפקידים שלו, הוא ממתין בסבלנות לאפליקציית האינטרנט שלכם שתבצע בקשה יוצאת, ואז נכנס לפעולה על ידי יירוט שלה. אתם יכולים להחליט מה ה-service worker יעשה עם הבקשה שנקלטה.

בחלק מהבקשות, הפעולה הכי טובה היא פשוט לאפשר לבקשה להמשיך לרשת, בדיוק כמו שהיה קורה אם לא היה Service Worker בכלל.

אבל בבקשות אחרות, אתם יכולים להשתמש במשהו גמיש יותר מהמטמון של ה-HTTP בדפדפן, ולהחזיר תשובה מהירה ואמינה בלי לדאוג לגבי הרשת. לשם כך, צריך להשתמש בחלק השני של הפאזל: Cache Storage API.

Cache Storage API

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

‫Cache Storage API פותח מגוון חדש לגמרי של אפשרויות, בכך שהוא נותן למפתחים שליטה מלאה על התוכן של המטמון. במקום להסתמך על שילוב של כותרות HTTP והיוריסטיקה מובנית של הדפדפן, Cache Storage API חושף גישה מבוססת-קוד לשמירה במטמון. ‫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. כדי להשתמש ביעילות ב-Cache Storage API, צריך קודם להגדיר את ההתנהגות של מטמון ה-HTTP.

מה אפשר לעשות עם ה-API החדש? הרבה דברים. הנה כמה דוגמאות לשימושים נפוצים שיהיה קשה או בלתי אפשרי לבצע רק באמצעות המטמון של HTTP:

  • השתמשו בגישה של "רענון ברקע" לתוכן שנשמר במטמון, שנקראת stale-while-revalidate.
  • להגדיר מגבלה על מספר הנכסים המקסימלי לשמירה במטמון, ולהטמיע מדיניות תפוגה מותאמת אישית כדי להסיר פריטים ברגע שמגיעים למגבלה הזו.
  • משווים בין תגובות רשת חדשות לתגובות שנשמרו בעבר במטמון כדי לבדוק אם משהו השתנה, ומאפשרים למשתמש לעדכן את התוכן (למשל, באמצעות לחצן) כשהנתונים באמת עודכנו.

מידע נוסף זמין במאמר The Cache API: A quick guide.

הסבר על ה-API

כמה דברים שחשוב לזכור לגבי עיצוב ה-API:

  • אובייקטים מסוג Request משמשים כמפתחות הייחודיים כשקוראים וכותבים למטמונים האלה. כדי להקל עליכם, אתם יכולים להעביר מחרוזת של כתובת URL כמו 'https://example.com/index.html' בתור המפתח במקום אובייקט Request בפועל, וה-API יטפל בזה בשבילכם באופן אוטומטי.
  • Response משמשים כערכים במטמונים האלה.
  • הכותרת Cache-Control ב-Response מסוים לא נלקחת בחשבון כששומרים נתונים במטמון. אין בדיקות אוטומטיות מובנות של תפוגה או עדכניות, וברגע שמאחסנים פריט במטמון, הוא נשאר שם עד שהקוד מסיר אותו באופן מפורש. (יש ספריות שמפשטות את תחזוקת המטמון בשבילכם. נדבר עליהם בהמשך הסדרה הזו).
  • בניגוד לממשקי API סינכרוניים ישנים יותר כמו LocalStorage, כל הפעולות של Cache Storage API הן אסינכרוניות.

סטייה קלה מהנושא: Promises ו-async/await

קובצי Service Worker ו-Cache Storage API משתמשים במושגים של תכנות אסינכרוני. במיוחד, הם מסתמכים במידה רבה על הבטחות לייצג את התוצאה העתידית של פעולות אסינכרוניות. לפני שמתחילים, כדאי להכיר את ההבטחות ואת התחביר הקשור של async/await.

אל תפרסו את הקוד הזה… עדיין

למרות שהם מספקים בסיס חשוב, ואפשר להשתמש בהם כמו שהם, גם קובצי ה-Service Worker וגם Cache Storage API הם למעשה אבני בניין ברמה נמוכה יותר, עם מספר מקרי קצה ו "מלכודות". יש כמה כלים ברמה גבוהה יותר שיכולים לעזור לכם להתגבר על החלקים הקשים של ממשקי ה-API האלה, ולספק את כל מה שאתם צריכים כדי ליצור Service Worker שמוכן לייצור. במדריך הבא נסביר על אחד מהכלים האלה: Workbox.