אתגרים ופתרונות עקיפים לבניית Progressive Web Apps באתרים עם כמה מקורות.
פורסם: 19 באוגוסט 2019
בעבר היו כמה יתרונות לשימוש בארכיטקטורות מרובות מקורות. הגישה הזו מציבה אתגרים רבים לאפליקציות Progressive Web App. בפרט, מדיניות המקור הזהה מטילה מגבלות על שיתוף של דברים כמו עובדי שירות ומטמון, הרשאות, ועל השגת חוויה עצמאית בכמה מקורות.
במאמר הזה נסביר מהם היתרונות והחסרונות של שימוש בכמה מקורות, ומהם האתגרים והפתרונות ליצירת 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) יכול לשלוט רק בדפים שמארחים תחת המקור והנתיב שאליהם הוא משתייך. המשמעות היא שאם קובץ השירות מתארח בכתובת https://www.example.com, הוא יכול לשלוט רק בכתובות URL מהמקור הזה (בהתאם לנתיב שמוגדר בפרמטר scope), אבל הוא לא ישלוט באף דף בתת-דומיינים אחרים, כמו למשל אלה בכתובת https://section.example.com.
במקרה כזה, הפתרון היחיד הוא להשתמש בכמה service workers (אחד לכל מקור).
שמירה במטמון
גם האובייקט Cache, indexedDB ו-localStorage מוגבלים למקור יחיד. המשמעות היא שאי אפשר לגשת למטמון ששייך ל-https://www.example.com, למשל מ-https://www.section.example.com.
כדי לנהל את מטמון הנתונים בצורה נכונה בתרחישים כאלה, אפשר לעשות את הפעולות הבאות:
שימוש במטמון של הדפדפן: תמיד מומלץ להשתמש בשיטות המומלצות המסורתיות לשימוש במטמון של הדפדפן. הטכניקה הזו מספקת יתרון נוסף של שימוש חוזר במשאבים שנשמרו במטמון בין מקורות שונים, מה שלא ניתן לעשות באמצעות המטמון של Service Worker. במאמר הזה מפורטות שיטות מומלצות לשימוש במטמון HTTP עם Service Workers.
שמירה על התקנה קלה של 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 עם כמה מקורות לפעול בצורה תקינה, אבל בדקנו כמה פתרונות אפשריים. כל אחת מהגישות האלה מגיעה עם פשרות, לכן חשוב להפעיל שיקול דעת כשמחליטים באיזו גישה להשתמש באתר.
כשמעריכים אסטרטגיה לטווח ארוך או עיצוב מחדש של אתר, כדאי לשקול מעבר למקור יחיד, אלא אם יש סיבה חשובה לשמור על ארכיטקטורה של כמה מקורות.
תודה רבה על הביקורות הטכניות וההצעות: פני מקלכלן, פול קובל, דומיניק נג, אלברטו מדינה, פיט לה-פייג', ג'ו מדלי, צ'ייני צאי, מרטין שירלה ואנדרה בנדרה.