אפליקציות מסוג Progressive Web App באתרים מרובי-מקורות

אתגרים ופתרונות אפשריים לפיתוח אפליקציות מסוג Progressive Web App באתרים מרובי מקורות.

Demián Renzulli

רקע

בעבר היו כמה יתרונות לשימוש בארכיטקטורות עם מקורות מרובים, אבל כשמדובר ב-Progressive Web Apps, הגישה הזו כללה אתגרים רבים. באופן ספציפי, מדיניות המקור הזהה כוללת הגבלות על שיתוף פרטים כמו Service worker ומטמון, הרשאות ולהשגת חוויה עצמאית בכמה מקורות. במאמר הזה נתאר את השימושים הטובים והרעים במקורות מרובים, ונסביר את האתגרים והפתרונות האפשריים לפיתוח אפליקציות מסוג Progressive Web App באתרים מרובי מקורות.

שימוש טוב ולא טוב בכמה מקורות

יש כמה סיבות לגיטימיות לאתרים להשתמש בארכיטקטורה מרובת מקורות, שקשורה בעיקר לאספקת קבוצה עצמאית של אפליקציות אינטרנט, או כדי ליצור חוויות מבודדות לחלוטין. יש גם שימושים שעדיף להימנע מהם.

הטוב

קודם נוסיף את הסיבות השימושיות:

• לוקליזציה / שפה: שימוש בדומיין ברמה העליונה עם קוד מדינה, כדי להפריד בין אתרים שיוצגו במדינות שונות (למשל 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) (אחד לכל מקור).

זהירות: רישום ועבודה עם מספר פריטי שירות פעילים (service worker) צורכים משאבים נוספים (זיכרון, מעבד (CPU) וכו'), לכן חשוב להפעיל שיקול דעת כדי לקבוע כמה עובדי שירות פעילים כנראה יצטרכו לנווט באתר.

שמירה במטמון

גם האובייקט Cache, IndexDB ו-localStorage מוגבלים למקור אחד. המשמעות היא שלא ניתן לגשת למטמון ששייך ל-https://www.example.com, למשל https://www.section.example.com.

הנה כמה דברים שאפשר לעשות כדי לנהל המטמון בצורה נכונה בתרחישים כמו:

• שימוש בשמירה במטמון הדפדפן: תמיד מומלץ להשתמש בשיטות מומלצות מסורתיות לשמירה במטמון בדפדפן. השיטה הזו מוסיפה יתרון של שימוש חוזר במשאבים שנשמרו במטמון במקורות שונים, ולא ניתן לעשות זאת באמצעות המטמון של קובץ השירות (service worker). לשיטות מומלצות לשימוש במטמון HTTP עם Service Worker, ניתן לעיין בפוסט הזה.

• הקפידו על התקנה קלה של קובצי שירות (service worker): אם יש לכם מספר קובצי שירות (service worker), רצוי לא לגרום למשתמשים לשלם עלות התקנה גדולה בכל פעם שהם עוברים למקור חדש. במילים אחרות: יש לשמור מראש רק משאבים חיוניים.

ברגע ש-Service Worker פעיל ופעיל, מדיניות המקור הזהה מגבילה גם בקשות ממקורות שונים המתבצעות בתוך Service Worker. למרבה המזל, יש דרך מומלצת לעקוף את הבעיה, שהיא שימוש ב-CORS (כפי שמוסבר כאן). לא מומלץ להשתמש במצב ללא קורות לאחזור משאבים בתוך קובץ השירות (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.

כדי לפתור את הבעיה הזו, אפשר לוודא שההנחיה מוצגת רק במקור הראשי. כשמשתמש מבקר בתת-דומיין שעומד בקריטריונים להתקנה:

1. האזנה לאירוע אחד (beforeinstallprompt).
2. מניעת ההופעה של ההצעה לפעולה, באמצעות קריאה ל-event.preventDefault().

כך תוכלו לוודא שההצעה לפעולה לא תוצג בחלקים לא רצויים של האתר, ובמקביל להמשיך להציג אותה, למשל, במקור הראשי (למשל בדף הבית).

מצב עצמאי

במהלך ניווט בחלון נפרד, הדפדפן יתנהג אחרת כשהמשתמש יחרוג מהיקף ההרשאות שהוגדר במניפסט של ה-PWA. ההתנהגות תלויה בכל גרסה וספק של הדפדפן. לדוגמה, הגרסאות האחרונות של Chrome פותחות כרטיסייה מותאמת ב-Chrome כשמשתמש יוצא מההיקף במצב עצמאי.

ברוב המקרים אין פתרון לבעיה הזו, אבל אפשר לעקוף את הבעיה בחלקים קטנים של חוויית המשתמש שמתארחים בתת-דומיינים (לדוגמה: תהליכי עבודה להתחברות):

1. כתובת ה-URL החדשה, https://login.example.com, עשויה להיפתח ב-iframe במסך מלא.
2. לאחר השלמת המשימה בתוך ה-iframe (לדוגמה, תהליך ההתחברות), ניתן להשתמש ב-postMessage() כדי להעביר כל מידע שמתקבל מה-iframe חזרה לדף ההורה.
3. בשלב האחרון, ברגע שההודעה מתקבלת בדף הראשי, ניתן לבטל את ההרשמה של המאזינים ולהסיר את ה-iframe מה-DOM.

זהירות: השיטה הקודמת יכולה לעזור לצמצם את השינוי הפוטנציאלי בממשק המשתמש בחלק קטן מהאתר, שבו המשתמש יכול לבצע פעולה בתת-דומיין ולחזור למקור הראשי (למשל בתהליך התחברות), אבל זו לא תהיה שיטה יעילה להטמעה של נתיבים שלמים, כולל דפים רבים שמתארחים בתת-דומיינים (כמו חלקים של אתר).

הערה: בהקשר של פעילויות מהימנות באינטרנט, יש דרך מומלצת למנוע את הבעיה הזו באמצעות אימות של כל המקורות באמצעות קישורים לנכסים דיגיטליים.

סיכום

מדיניות המקור הזהה מחילה הגבלות רבות על אתרים שמבוססים על כמה מקורות שרוצים לספק חוויית PWA קוהרנטית. לכן, כדי לספק למשתמשים את החוויה הטובה ביותר, מומלץ מאוד לא לחלק אתרים למקורות שונים.

באתרים קיימים שכבר בנויים בצורה הזו יכול להיות מאתגר לגרום לאפליקציות PWA מרובות מקורות לפעול בצורה תקינה, אבל בדקנו כמה פתרונות אפשריים. לכל אחת מהן יכולות להיות השלכות שונות, לכן חשוב להפעיל שיקול דעת כשאתם מחליטים איזו גישה לנקוט באתר שלכם.

כשאתם בוחנים אסטרטגיה לטווח ארוך או עיצוב מחדש של אתר, כדאי לעבור למקור אחד, אלא אם יש סיבה חשובה להשאיר את הארכיטקטורה מרובת המקורות.

תודה רבה על הביקורות הטכניות וההצעות שהם שולחים: פני מקלכלן, פול קובל, דומיניק נג, אלברטו מדינה, פט להפיז, ג'ו מדלי, צ'יני טסאי, מרטין שיירל ואנדרה בנדרה.