אתם נעולים במאבק על אמינות הרשת. מטמון ה-HTTP של הדפדפן הוא קו ההגנה הראשון, אבל כפי שלמדתם, הוא יעיל מאוד רק לטעינת כתובות URL עם גרסאות שבהן ביקרתם בעבר. לכשעצמו, המטמון של HTTP לא מספיק.
למרבה המזל, יש שני כלים חדשים יותר שיכולים לעזור לכם לגאות לטובתכם: service worker ו-Cache Storage API. בגלל השימוש בהם כל כך הרבה פעמים, חשוב ללמוד על שניהם בו-זמנית.
קובצי שירות (service worker)
קובץ שירות (service worker) מובנה בדפדפן, ונשלט על ידי קוד JavaScript נוסף שאחראי ליצירתו. אתם פורסים אותו לצד הקבצים האחרים שמרכיבים את אפליקציית האינטרנט שלכם.
ל-Service Worker יש כמה כוחות מיוחדים. בין שאר התפקידים, הוא ממתין בסבלנות שאפליקציית האינטרנט תבצע בקשה יוצאת, ואז נכנס לפעולה על ידי יירוט שלה. אתם קובעים מה ה-Service Worker עושה עם הבקשה המיורטת.
בבקשות מסוימות, דרך הפעולה הטובה ביותר יכולה להיות רק לאפשר לבקשה להמשיך ברשת, בדיוק כמו מה היה קורה אם לא היה קובץ שירות (service worker) בכלל.
עם זאת, בבקשות אחרות אפשר להשתמש במשהו גמיש יותר ממטמון ה-HTTP של הדפדפן, ולהחזיר תגובה מהירה ואמינה בלי לדאוג לגבי הרשת. זה כולל שימוש בחלק השני של החידה: Cache Storage API.
ממשק ה-API של 'אחסון המטמון'
ה-API של 'אחסון המטמון' פותח מגוון אפשרויות חדשות, כי הוא נותן למפתחים שליטה מלאה על תוכן המטמון. במקום להסתמך על שילוב של כותרות HTTP וheuristics המובנית של הדפדפן, ה-API לאחסון במטמון חושף גישה מבוססת קוד לשמירה במטמון. ה-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 בלבד הם:
- כדאי להשתמש בגישת "רענון ברקע" כדי לרענן תוכן שנשמר במטמון, שנקראת 'לא פעיל בזמן אימות מחדש'.
- קבעו מכסה למספר הנכסים המקסימלי לשמירה במטמון, והשתמשו במדיניות תפוגה מותאמת אישית כדי להסיר פריטים כשתגיעו למגבלה.
- אתם יכולים להשוות בין תגובות רשת שנשמרו במטמון לבין תגובות חדשות שנשמרו במטמון כדי לראות אם משהו השתנה, ולאפשר למשתמש לעדכן את התוכן (למשל, באמצעות לחצן) כשהנתונים עודכנו בפועל.
למידע נוסף, כדאי לעיין במאמר The Cache API: מדריך מהיר.
אומים וברגים ל-API
יש כמה דברים שכדאי לזכור לגבי העיצוב של ה-API:
Requestאובייקטים משמשים כמפתחות ייחודיים לקריאה וכתיבה במטמון הזה. לנוחותך, ניתן להעביר מחרוזת של כתובת URL כמו'https://example.com/index.html'כמפתח במקום כאובייקטRequestבפועל, וה-API יטפל בכך באופן אוטומטי.- אובייקטים מסוג
Responseמשמשים כערכים במטמון הזה. - כששומרים נתונים במטמון, המערכת מתעלמת מהכותרת
Cache-Controlב-Responseנתון. אין בדיקות תפוגה או עדכניות באופן אוטומטי ומובנות, ואחרי שמאחסנים פריט במטמון הוא נשאר בתוקף עד שהקוד יסיר אותו באופן מפורש. (יש ספריות שתוכלו להשתמש בהן כדי לפשט את התחזוקה של המטמון. נעסוק בהם בהמשך הסדרה.) - בשונה מממשקי API סינכרוניים ישנים יותר, כמו
LocalStorage, כל הפעולות של Cache Storage API הן אסינכרוניות.
דרך עוקפת מהירה: הבטחות ואסינכרוניות/המתנה
ב-Service Workers וב-Cache Storage API משתמשים במושגי תכנות אסינכרוניים.
באופן ספציפי, הם מסתמכים בעיקר על הבטחות לייצוג התוצאה העתידית של פעולות אסינכרוניות. כדאי להכיר את הבטחות ואת התחביר הרלוונטי async/await לפני שמתחילים.
לא לפרוס את הקוד הזה... עדיין
הם מספקים בסיס חשוב וניתן להשתמש בהם כפי שהם, אבל גם Service Workers וגם ה-API של אחסון המטמון הם למעשה אבני בניין ברמה נמוכה יותר, עם מספר כיסויי קצה ו "טעויות". יש כמה כלים ברמה גבוהה יותר שיכולים לעזור לכם להחליק את החלקים הקשות של ממשקי ה-API האלה, ולספק את כל מה שצריך כדי לבנות Service Worker שמוכן לייצור. במדריך הבא נסביר על כלי אחד כזה: תיבת עבודה.