אתגרים ופתרונות עקיפים לבניית Progressive Web Apps באתרים מרובי מקורות.
רקע
בעבר היו כמה יתרונות לשימוש בארכיטקטורות עם מספר מקורות, אבל גישה זו מעמידה אתגרים רבים בקרב אפליקציות אינטרנט מסוג Progressive Web App. באופן ספציפי, מדיניות המקור הזהה אוכפת מגבלות על שיתוף פריטים כמו Service worker, מטמון, הרשאות והשגת חוויה עצמאית במספר מקורות. במאמר הזה נתאר את השימושים הטובים והגרועים במספר מקורות, ונסביר את האתגרים והפתרונות העקיפים לבניית Progressive Web Apps באתרים מרובי מקורות.
שימושים טובים ורעים בכמה מקורות
יש כמה סיבות לגיטימיות לכך שאתרים ישתמשו בארכיטקטורה מרובת מקורות, שקשורות בעיקר לאספקת קבוצה עצמאית של אפליקציות אינטרנט או ליצירת חוויות שמבודדות לחלוטין זו מזו. יש גם שימושים שצריך להימנע מהם.
הטוב
תחילה נבחן את הסיבות המועילות:
לוקליזציה / שפה: שימוש בדומיין ברמה העליונה של קוד מדינה, כדי להפריד אתרים עם הצגת מודעות במדינות שונות (למשל
https://www.google.com.ar), או שימוש בתת-דומיינים כדי לחלק אתרים שמטרגטים מיקומים שונים (למשל:https://newyork.craigslist.org) או כדי להציע תוכן בשפה מסוימת (למשל,https://en.wikipedia.org).אפליקציות אינטרנט עצמאיות: שימוש בתת-דומיינים שונים כדי לספק חוויות שהמטרה שלהן שונה במידה משמעותית מזו של האתר במקור הראשי. למשל, באתר חדשות ניתן להציג באופן מכוון את אפליקציית האינטרנט של התשבצים מ-
https://crosswords.example.com, להתקין אותה ולהשתמש בה כ-PWA עצמאי, בלי לשתף משאבים או פונקציונליות כלשהם עם האתר הראשי.
גרוע
אם לא תבצעו אף אחת מהפעולות האלה, סביר להניח ששימוש בארכיטקטורה מרובת מקורות יהווה יתרון של הבנייה של Progressive Web Apps.
למרות זאת, אתרים רבים ממשיכים להיות בנויים בצורה כזו ללא סיבה מסוימת, או מסיבות 'קודמות'. דוגמה אחת היא שימוש בתת-דומיינים כדי להפריד באופן שרירותי בין חלקים של אתר שצריכים להיכלל בחוויה מאוחדת.
מומלץ מאוד לא ליישם את הדפוסים הבאים:
חלקי אתרים: הפרדת קטעים שונים של אתר בתת-דומיינים. באתרי חדשות, לעתים קרובות מוצג דף הבית בכתובת:
https://www.example.com, ואילו מדור הספורט נמצא בכתובתhttps://sports.example.com, פוליטיקה ב-https://politics.example.comוכן הלאה. במקרה של אתר מסחר אלקטרוני, שימוש בשם כמוhttps://category.example.comלקטגוריות מוצרים,https://product.example.comלדפי מוצרים וכו'.זרימת משתמש: גישה נוספת לא מומלצת היא להפריד בין חלקים קטנים יותר של האתר, כגון דפים להתחברות או לתהליכי רכישה בתת-דומיינים. לדוגמה, באמצעות
https://login.example.comו-https://checkout.example.com.
במקרים שבהם אין אפשרות לבצע העברה למקור יחיד, מוצגת רשימה של אתגרים ופתרונות עקיפים שניתן להביא בחשבון במהלך הפיתוח של Progressive Web Apps.
אתגרים ופתרונות לעקיפת אפליקציות PWA ממקורות שונים
כשבונים אתר בכמה מקורות, קשה לספק חוויית PWA אחידה, בעיקר בגלל מדיניות המקור הזהה, שמציבה כמה אילוצים. בואו נסתכל על זה אחר זה.
קובצי שירות (service worker)
מקור כתובת ה-URL של הסקריפט של Service Worker צריך להיות זהה למקור של הדף שקורא ל-register(). המשמעות היא, לדוגמה, שבדף ב-https://www.example.com לא ניתן להפעיל את register() עם כתובת URL של קובץ שירות (service worker) ב-https://section.example.com.
שיקול נוסף הוא שה-Service Worker יכול לשלוט רק בדפים שמתארחים במקור ובנתיב שאליו הוא שייך. כלומר, אם קובץ השירות (service worker) מתארח ב-https://www.example.com, הוא יכול לשלוט רק בכתובות URL מהמקור הזה (בהתאם לנתיב שהוגדר בפרמטר ההיקף), אבל לא שולט באף דף בתת-דומיינים אחרים כמו למשל, אלה שנמצאים בתת-הדומיין https://section.example.com.
במקרה הזה, הדרך היחידה לעקוף את הבעיה היא להשתמש בכמה קובצי שירות (service worker) (אחד לכל מקור).
שמירה במטמון
אובייקט המטמון, IndexDB ו-localStorage מוגבלים גם הם למקור יחיד. פירוש הדבר שלא ניתן לגשת למטמון ששייך ל-https://www.example.com, למשל: https://www.section.example.com.
הנה כמה דברים שאפשר לעשות כדי לנהל קבצים שמורים כראוי בתרחישים כאלה:
למנף את השמירה במטמון הדפדפן: תמיד מומלץ להשתמש בשיטות מומלצות לשמירה במטמון בדפדפן. השיטה הזו מספקת יתרון נוסף של שימוש חוזר במשאבים שנשמרו במטמון במקורות שונים, ואי אפשר לעשות זאת באמצעות המטמון של ה-Service Worker. לשיטות מומלצות לשימוש במטמון HTTP עם קובצי שירות (service worker), ניתן לקרוא את הפוסט הזה.
התקינה של קובצי שירות (service worker) פשוטה: אם אתם מתחזקים מספר קובצי שירות (service worker), אל תגרמו למשתמשים לשלם עלות התקנה גבוהה בכל פעם שהם עוברים למקור חדש. במילים אחרות: שמרו מראש רק משאבים שנחוצים לחלוטין.
הרשאות
ההרשאות מוגבלות גם למקורות. המשמעות היא שאם משתמש העניק הרשאה נתונה למקור https://section.example.com, היא לא תועבר למקורות אחרים, כמו https://www.example.com.
אין דרך לשתף הרשאות בין מקורות, לכן הפתרון היחיד כאן הוא לבקש הרשאה בכל אחד מתת-הדומיינים שבהם נדרשת תכונה מסוימת (למשל, מיקום). לדברים כמו דחיפה של אינטרנט, ניתן לנהל קובץ cookie כדי לעקוב אם ההרשאה אושרה על ידי המשתמש בתת-דומיין אחר, על מנת להימנע מלבקש אותה שוב.
התקנה
כדי להתקין PWA, לכל מקור צריך להיות מניפסט משלו עם start_url שהוא יחסי לעצמו. המשמעות היא שמשתמש שמקבל את בקשת ההתקנה במקור נתון (למשל: https://section.example.com) לא יוכל להתקין את ה-PWA באמצעות start_url במקור אחר (כלומר: https://www.example.com).
במילים אחרות, משתמשים שיקבלו את בקשת ההתקנה בתת-דומיין יוכלו להתקין אפליקציות PWA רק לדפי המשנה, ולא לכתובת ה-URL הראשית של האפליקציה.
בנוסף, אותו משתמש עלול לקבל מספר בקשות התקנה במהלך הניווט באתר, אם כל תת-דומיין עומד בקריטריונים להתקנה, ומתבקש למשתמש להתקין את ה-PWA.
כדי לצמצם את הבעיה, אפשר לוודא שההצעה תוצג רק במקור הראשי. כשמשתמש מבקר בתת-דומיין שעומד בקריטריונים להתקנה:
- האזנה לאירוע אחד (
beforeinstallprompt). - מניעת הופעת הבקשה, התקשרות ל-
event.preventDefault().
כך תוכלו לוודא שההצעה לא תוצג בחלקים לא רצויים של האתר, ובמקביל תוכלו להמשיך להציג אותה, למשל במקור הראשי (למשל, דף הבית).
מצב עצמאי
בניווט בחלון נפרד, הדפדפן יתנהג אחרת כשהמשתמש יוצא מחוץ להיקף שהוגדר במניפסט של ה-PWA. ההתנהגות תלויה בכל גרסת דפדפן ובכל ספק. לדוגמה, הגרסאות העדכניות של Chrome פותחות כרטיסייה מותאמת אישית ב-Chrome, כשמשתמש יוצא מהיקף ההרשאות במצב עצמאי.
ברוב המקרים אין פתרון לבעיה הזו, אבל אפשר לעקוף את הבעיה בחלקים קטנים של החוויה שמתארחים בתת-דומיינים (לדוגמה: תהליכי עבודה של התחברות):
- כתובת ה-URL החדשה,
https://login.example.com, עשויה להיפתח ב-iframe במסך מלא. - לאחר השלמת המשימה ב-iframe (לדוגמה, תהליך ההתחברות), אפשר להשתמש ב-postMessage() כדי להעביר את המידע שמתקבל מה-iframe בחזרה לדף ההורה.
- בשלב האחרון, לאחר שההודעה מתקבלת בדף הראשי, ניתן לבטל את הרישום של המאזינים ואז להסיר את ה-iframe בסופו של דבר מה-DOM.
סיכום
המדיניות לגבי אותו מקור מטילה הגבלות רבות על אתרים שנבנו מעל כמה מקורות ורוצים להשיג חוויית PWA עקבית. לכן, כדי לספק למשתמשים את החוויה הטובה ביותר, מומלץ לא לחלק את האתרים למקורות שונים.
באתרים קיימים שכבר נבנים בצורה כזו, יכול להיות מאתגר לאמן כראוי אפליקציות PWA ממקורות מרובים, אבל בדקנו כמה פתרונות אפשריים. לכל רמה יש יתרונות וחסרונות, לכן חשוב להפעיל שיקול דעת כשתחליטו באיזו גישה לבחור באתר שלכם.
כשבוחנים אסטרטגיה לטווח ארוך או תכנון מחדש של האתר, כדאי לעבור למקור יחיד, אלא אם יש סיבה חשובה להשאיר את הארכיטקטורה מרובת מקורות.
עם הרבה תודה על הביקורות הטכניות וההצעות: פני מקלכלן, פול קובל, דומיניק נג, אלברטו מדינה, פיט לפיג', ג'ו מדלי, צ'ייני טסאי, מרטין שירל ואנדרה בנדרה.