אתם נאבקים כדי לשמור על אמינות הרשת. מטמון ה-HTTP של הדפדפן הוא קו ההגנה הראשון, אבל כפי שלמדתם, הוא יעיל רק כשמטענים כתובות URL עם גרסאות שכבר ביקרתם בהן. מטמון ה-HTTP לא מספיק בפני עצמו.
למרבה המזל, יש שני כלים חדשים שיכולים לעזור לכם להפוך את המצב לטובתכם: שירותי עבודה ו-Cache Storage API. מכיוון שהם משמשים יחד לעיתים קרובות, כדאי ללמוד על שניהם בו-זמנית.
קובצי שירות (service worker)
עובד שירות מוטמע בדפדפן ומנוהל על ידי קטע נוסף של קוד JavaScript שאתם אחראים ליצור. פורסים אותו לצד הקבצים האחרים שמרכיבים את אפליקציית האינטרנט בפועל.
ל-service worker יש כמה יכולות מיוחדות. בין היתר, הוא מחכה בסבלנות לאפליקציית האינטרנט ששולחת בקשה יוצאת, ואז פותח במבצע על ידי ניתוב אותה. אתם קובעים מה יעשה עובד השירות עם הבקשה שחוסמה.
בחלק מהבקשות, הדרך הטובה ביותר היא פשוט לאפשר לבקשה להמשיך לרשת, בדיוק כמו שקורה אם אין כלל שירות לניהול בקשות (service worker).
עם זאת, לבקשות אחרות אפשר להשתמש בפתרון גמיש יותר מאשר המטמון של HTTP בדפדפן, ולהחזיר תגובה מהירה ואמינה בלי לדאוג לגבי הרשת. לשם כך צריך להשתמש בחלק השני של הפאזל: Cache Storage API.
Cache Storage API
Cache Storage API פותח מגוון אפשרויות חדש לגמרי, ומעניק למפתחים שליטה מלאה על תוכן המטמון. במקום להסתמך על שילוב של כותרות HTTP ושיטות ניתוח נתונים מובנות בדפדפן, Cache Storage API חושף גישה מבוססת-קוד לשמירת נתונים במטמון. ה-API של אחסון במטמון שימושי במיוחד כשקוראים לו מ-JavaScript של ה-service worker.
רגע… יש עוד מטמון שצריך להביא בחשבון עכשיו?
בטח עולות לכם שאלות כמו "האם עדיין צריך להגדיר את כותרות ה-HTTP?" ו"מה אפשר לעשות עם המטמון החדש הזה שלא היה אפשרי עם מטמון ה-HTTP?" אל דאגה – אלה תגובות טבעיות.
עדיין מומלץ להגדיר את הכותרות Cache-Control
בשרת האינטרנט, גם אם אתם יודעים שאתם משתמשים ב-Cache Storage API. בדרך כלל אפשר להגדיר את הערך Cache-Control: no-cache
לכתובות URL ללא גרסאות, ו/או את הערך Cache-Control: max-age=31536000
לכתובות URL שמכילות פרטי גרסאות, כמו גיבוב (hash).
כשמאכלסים את המטמון של API של אחסון במטמון, הדפדפן מחפש כברירת מחדל רשומות קיימות במטמון ה-HTTP, ומשתמש בהן אם הוא מוצא אותן. אם מוסיפים כתובות URL עם גרסאות למטמון של API של אחסון במטמון, הדפדפן ימנע בקשת רשת נוספת. עם זאת, אם משתמשים בכותרות Cache-Control
שהוגדרו בצורה שגויה, למשל ציון תוחלת חיים ארוכה של נתוני מטמון לכתובת URL ללא גרסה, הוספת התוכן הלא עדכני הזה ל-Cache Storage API עלולה להחמיר את המצב. כדי להשתמש ביעילות ב-Cache Storage API, צריך לסדר את התנהגות המטמון של HTTP.
מה אפשר לעשות עכשיו עם ה-API החדש הזה? הרבה. דוגמאות לשימושים נפוצים שיהיה קשה או בלתי אפשרי לבצע רק באמצעות מטמון ה-HTTP:
- שימוש בגישה של 'רענון ברקע' לתוכן שנשמר במטמון, שנקראת 'לא עדכני בזמן אימות מחדש'.
- להגדיר מגבלה על המספר המקסימלי של נכסים שאפשר לשמור במטמון, ולהטמיע מדיניות תפוגה מותאמת אישית כדי להסיר פריטים אחרי שמגיעים למגבלה הזו.
- להשוות בין תשובות מהרשת שנשמרו במטמון לבין תשובות עדכניות מהרשת כדי לראות אם יש שינוי, ולאפשר למשתמש לעדכן את התוכן (למשל באמצעות לחצן) כשהנתונים עודכנו בפועל.
מידע נוסף זמין במאמר Cache API: מדריך מהיר.
היסודות של ממשקי API
יש כמה דברים שכדאי לזכור לגבי העיצוב של ה-API:
- אובייקטים מסוג
Request
משמשים כמפתחות הייחודיים בזמן הקריאה והכתיבה במטמון. כדי להקל עליכם, תוכלו להעביר מחרוזת של כתובת URL כמו'https://example.com/index.html'
כמפתח במקום אובייקטRequest
בפועל, וה-API יטפל בזה בשבילכם באופן אוטומטי. - אובייקטים מסוג
Response
משמשים כערכים במטמון. - המערכת מתעלמת מהכותרת
Cache-Control
ב-Response
נתון כשהנתונים מאוחסנים במטמון. אין בדיקות אוטומטיות מובנות של תאריך תפוגה או עדכניות, וברגע ששומרים פריט במטמון, הוא נשאר שם עד שהקוד מסיר אותו באופן מפורש. (יש ספריות שמפשטות את התחזוקה של המטמון בשבילכם. נרחיב עליהם בהמשך הסדרה). - בניגוד לממשקי API אסינכררוניים ישנים יותר כמו
LocalStorage
, כל הפעולות של Cache Storage API הן אסינכררוניות.
סטייה קצרה: הבטחות (promises) ו-async/await
ב-Service Workers וב-Cache Storage API נעשה שימוש במושגי תכנות אסינכרוניים.
במיוחד, הם מסתמכים במידה רבה על הבטחות (promises) כדי לייצג את התוצאה העתידית של פעולות אסינכרוניות. לפני שמתחילים, כדאי להכיר את ההבטחות ואת התחביר הקשור async
/await
.
אל תפרסו את הקוד הזה… עדיין
הם מספקים בסיס חשוב וניתן להשתמש בהם כפי שהם, אבל גם שירותי העובדים וגם Cache Storage API הם למעשה אבני בניין ברמה נמוכה יותר, עם מספר מקרים קיצוניים ו "מלכודות". יש כמה כלים ברמה גבוהה יותר שיכולים לעזור לכם להתגבר על החלק הקשה של ממשקי ה-API האלה, ולספק לכם את כל מה שדרוש כדי ליצור שירות פעיל (service worker) מוכן לייצור. במדריך הבא נסביר על כלי כזה: Workbox.