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