אתגרים ופתרונות זמניים ליצירת אפליקציות אינטרנט מתקדמות (PWA) באתרים עם כמה מקורות.
רקע
בעבר היו כמה יתרונות לשימוש בארכיטקטורות עם מקורות מרובים, אבל לגבי אפליקציות אינטרנט מתקדמות, הגישה הזו מציבה אתגרים רבים. באופן ספציפי, מדיניות המקור הזהה מטילה הגבלות על שיתוף פריטים כמו שירותי עובדים (service workers) ומטמון, הרשאות, ועל יצירת חוויה עצמאית בכמה מקורות. במאמר הזה נתאר את היתרונות והחסרונות של שימוש בכמה מקורות, ונסביר על האתגרים והפתרונות הזמינים ליצירת אפליקציות אינטרנט מתקדמות (PWA) באתרים עם כמה מקורות.
שימוש נכון ולא נכון במספר מקורות
יש כמה סיבות לגיטימיות לשימוש בארכיטקטורה עם מקורות מרובים באתרים, בעיקר שקשורות לספק קבוצה עצמאית של אפליקציות אינטרנט או ליצור חוויות מבודדות לחלוטין זו מזו. יש גם שימושים שצריך להימנע מהם.
הטוב
קודם נציג את הסיבות המועילות:
התאמה לשוק המקומי / שפה: שימוש בדומיין ברמה העליונה עם קוד מדינה כדי להפריד בין אתרים שמוצגים במדינות שונות (למשל
https://www.google.com.ar), או שימוש בתת-דומיינים כדי לפצל אתרים שמטורגטים למיקומים שונים (למשל:https://newyork.craigslist.org) או להציע תוכן בשפה ספציפית (למשלhttps://en.wikipedia.org).אפליקציות אינטרנט עצמאיות: שימוש בתת-דומיינים שונים כדי לספק חוויות שהמטרה שלהן שונה באופן משמעותי מהאתר במקור הראשי. לדוגמה, באתר חדשות, אפשר להציג את אפליקציית האינטרנט של תשבצי הקריקטורה בכוונה מ-
https://crosswords.example.com, להתקין אותה ולהשתמש בה כ-PWA עצמאי, בלי שתצטרכו לשתף משאבים או פונקציונליות עם האתר הראשי.
הצדדים השליליים
אם אתם לא עושים אף אחת מהפעולות האלה, סביר להניח שהשימוש בארכיטקטורה עם מקורות מרובים יהיה לרעתכם כשאתם יוצרים אפליקציות אינטרנט מתקדמות.
למרות זאת, הרבה אתרים ממשיכים להיות מובנים כך ללא סיבה מיוחדת, או מסיבות 'היסטוריות'. דוגמה אחת היא שימוש בתת-דומיינים כדי להפריד באופן שרירותי חלקים באתר שצריכים להיות חלק מחוויה מאוחדת.
לדוגמה, מומלץ מאוד להימנע מהדפוסים הבאים:
קטעים באתר: הפרדת קטעים שונים באתר בתת-דומיינים. באתרי חדשות, לא נדיר לראות את דף הבית בכתובת:
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.
אתגרים ופתרונות עקיפים ל-PWAs במקורות שונים
כשאתם בונים אתר בכמה מקורות, קשה לספק חוויית PWA אחידה, בעיקר בגלל מדיניות המקור הזהה, שמטילה כמה אילוצים. נבחן אותם אחד אחרי השני.
קובצי שירות (service worker)
המקור של כתובת ה-URL של סקריפט ה-service worker צריך להיות זהה למקור של הדף שמפעיל את register(). כלומר, לדוגמה, דף בכתובת https://www.example.com לא יכול להפעיל את register() עם כתובת URL של service worker בכתובת https://section.example.com.
שיקול נוסף הוא שקובץ שירות יכול לשלוט רק בדפים שמתארחים במקור ובנתיב שהוא שייך אליהם. כלומר, אם קובץ השירות מתארח ב-https://www.example.com, הוא יכול לשלוט רק בכתובות URL מהמקור הזה (בהתאם לנתיב שמוגדר בפרמטר ההיקף), אבל הוא לא ישלוט בדפים בתת-דומיינים אחרים, כמו למשל אלה ב-https://section.example.com.
במקרה כזה, הפתרון היחיד הוא להשתמש בכמה שירותי עובדים (אחד לכל מקור).
שמירה במטמון
גם האובייקט Cache, indexedDB ו-localStorage מוגבלים למקור יחיד. המשמעות היא שלא ניתן לגשת למטמון ששייך ל-https://www.example.com, למשל: https://www.section.example.com.
הנה כמה דברים שאפשר לעשות כדי לנהל את המטמון בצורה תקינה בתרחישים כאלה:
שימוש במטמון הדפדפן: תמיד מומלץ להשתמש בשיטות המומלצות המסורתיות לשמירת נתונים במטמון הדפדפן. הטכניקה הזו מספקת את היתרון הנוסף של שימוש חוזר במשאבים שנשמרו במטמון במקורות שונים, דבר שלא ניתן לעשות באמצעות המטמון של ה-service worker. בפוסט הזה מפורטות שיטות מומלצות לשימוש במטמון HTTP עם שירותי עבודה.
שמירה על התקנה קלה של שירותי עבודה: אם אתם מטפלים בכמה שירותי עבודה, חשוב להימנע מהעלות גבוהה של התקנה בכל פעם שהמשתמשים עוברים למקור חדש. במילים אחרות: כדאי לשמור במטמון רק משאבים שדרושים באופן מוחלט.
הרשאות
ההרשאות מוגדרות גם ברמת המקור. המשמעות היא שאם משתמש העניק הרשאה מסוימת למקור https://section.example.com, היא לא תועבר למקורות אחרים, כמו https://www.example.com.
מכיוון שאין דרך לשתף הרשאות בין מקורות שונים, הפתרון היחיד הוא לבקש הרשאה בכל תת-דומיין שבו נדרשת תכונה מסוימת (למשל, מיקום). למשל, כדי להשתמש בהתראות דחיפה לאינטרנט, אפשר לשמור קובץ cookie כדי לעקוב אחרי אישור ההרשאה על ידי המשתמש בדומיין משנה אחר, וכך להימנע מהגשת בקשה חוזרת.
התקנה
כדי להתקין אפליקציית PWA, לכל מקור צריך להיות מניפסט משלו עם start_url שיחסי לעצמו. המשמעות היא שמשתמש שמקבל את הבקשה להתקנה במקור נתון (למשל: https://section.example.com) לא יוכל להתקין את אפליקציית ה-PWA עם start_url במקור אחר (למשל: https://www.example.com). Autrement dit, des utilisateurs qui reçoivent la demande d'installation dans un sous-domaine pourront installer des applications PWA uniquement pour les pages de sous-domaine, et non pour l'adresse URL principale de l'application.
יש גם את הבעיה שלפיה אותו משתמש יכול לקבל מספר הנחיות התקנה בזמן הניווט באתר, אם כל תת-דומיין עומד בקריטריונים להתקנה ומבקש מהמשתמש להתקין את אפליקציית ה-PWA.
כדי לצמצם את הבעיה הזו, אפשר לוודא שההנחיה תוצג רק במקור הראשי. כשמשתמש מבקר בדומיין משנה שעובר את קריטריונים ההתקנה:
- האזנה לאירוע
beforeinstallprompt. - מניעת הצגת ההודעה, באמצעות קריאה לפונקציה
event.preventDefault().
כך תוכלו לוודא שההנחיה לא תוצג בחלקים לא רצויים באתר, ועדיין להמשיך להציג אותה, למשל, במקור הראשי (למשל, דף הבית).
מצב עצמאי
כשמנווטים בחלון עצמאי, הדפדפן יתנהג בצורה שונה כשהמשתמש יעבור מחוץ להיקף שהוגדר במניפסט של אפליקציית ה-PWA. ההתנהגות תלויה בגרסה ובספק של כל דפדפן. לדוגמה, בגרסאות האחרונות של Chrome נפתחת כרטיסייה בהתאמה אישית של Chrome כשמשתמש יוצא מההיקף במצב עצמאי.
ברוב המקרים אין פתרון לבעיה הזו, אבל אפשר להשתמש בפתרון עקיף בחלקים קטנים של חוויית המשתמש שמתארחים בתת-דומיינים (לדוגמה: תהליכי עבודה של כניסה לחשבון):
- כתובת ה-URL החדשה,
https://login.example.com, עשויה להיפתח בתוך iframe במסך מלא. - אחרי שהמשימה הושלמה בתוך ה-iframe (לדוגמה, תהליך הכניסה), אפשר להשתמש ב-postMessage() כדי להעביר את כל המידע שנוצר מה-iframe בחזרה לדף ההורה.
- בשלב האחרון, אחרי שההודעה מתקבלת בדף הראשי, אפשר לבטל את הרישום של המאזינים ולהסיר את ה-iframe מ-DOM.
סיכום
מדיניות המקור הזהה מטילה הגבלות רבות על אתרים שנוצרו על סמך כמה מקורות, שרוצים לספק חוויית שימוש עקבית של אפליקציות PWA. לכן, כדי לספק למשתמשים את חוויית השימוש הטובה ביותר, מומלץ מאוד לא לחלק אתרים למקורות שונים.
לאתרים קיימים שכבר נוצרו בצורה הזו, יכול להיות שיהיה קשה לגרום לאפליקציות PWA עם כמה מקורות לעבוד בצורה תקינה, אבל בדקנו כמה פתרונות אפשריים. לכל אחת מהגישות האלה יש יתרונות וחסרונות, לכן כדאי להפעיל שיקול דעת כשמחליטים איזו גישה ליישם באתר.
כשבודקים אסטרטגיה לטווח ארוך או עיצוב מחדש של אתר, כדאי לשקול לעבור למקור יחיד, אלא אם יש סיבה חשובה לשמור על הארכיטקטורה של כמה מקורות.
תודה רבה על הבדיקות הטכניות וההצעות: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle ו-Andre Bandarra.