יצירה של כמה אפליקציות מסוג Progressive Web App באותו דומיין

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

Chase Phillips

Demián Renzulli

Matt Giuca

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

דוגמה לארכיטקטורה כזו של אתר היא אתר מסחר אלקטרוני שבו:

• דף הבית נמצא בכתובת https://www.example.com.
• דפי הקטגוריות מתארחים בכתובת https://category.example.com.
• דפי פרטי המוצר בכתובת https://product.example.com.

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

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

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

מונחים טכניים

• דומיין: כל רצף של תוויות כפי שהוגדר במערכת שמות הדומיינים (DNS). לדוגמה: com ו-example.com הם דומיינים.
• שם מארח: רשומה ב-DNS שמתרגמת לכתובת IP אחת לפחות. לדוגמה: www.example.com הוא שם מארח, example.com יכול להיות שם מארח אם יש לו כתובת IP, ו-com אף פעם לא יפוענח לכתובת IP ולכן אף פעם לא יוכל להיות שם מארח.
• מקור: שילוב של סכמה, שם מארח ויציאה (אופציונלי). לדוגמה, https://www.example.com:443 הוא מקור.

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

למה כדאי ליצור כמה אפליקציות PWA קשורות

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

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

שימוש במקורות נפרדים

הגישה המומלצת במקרים כאלה היא שכל אפליקציה שונה מבחינה מושגית תהיה זמינה במקור משלה.

אם רוצים להשתמש באותו שם דומיין בכל אחד מהם, אפשר לעשות זאת באמצעות תת-דומיינים. לדוגמה, חברה שמספקת כמה אפליקציות או שירותים באינטרנט יכולה לארח אפליקציית אימייל בכתובת https://mail.example.com ואפליקציית יומן בכתובת https://calendar.example.com, תוך שהיא מציעה את השירות הראשי של העסק בכתובת https://www.example.com. דוגמה נוספת היא אתר ספורט שרוצה ליצור אפליקציה עצמאית שמוקדשת לחלוטין לאירוע ספורט חשוב, כמו אליפות כדורגל ב-https://footballcup.example.com, שמשתמשים יכולים להתקין ולהשתמש בה בנפרד מהאתר הראשי של הספורט שמתארח ב-https://www.example.com. הגישה הזו עשויה להתאים גם לפלטפורמות שמאפשרות ללקוחות ליצור אפליקציות עצמאיות משלהם במסגרת המותג של החברה. לדוגמה, אפליקציה שמאפשרת למוכרים ליצור אפליקציות PWA משלהם בכתובות https://merchant1.example.com,‏ https://merchant2.example.com וכו'.

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

• התקנה: לכל אפליקציה יש מניפסט משלה והיא מספקת חוויית התקנה משלה.
• אחסון: לכל אפליקציה יש מטמון משלה, אחסון מקומי ובעצם כל סוגי האחסון המקומי במכשיר, בלי לשתף אותם עם האפליקציות האחרות.
• Service Workers: לכל אפליקציה יש service worker משלה להיקפי הגישה הרשומים.
• הרשאות: ההרשאות מוגדרות גם לפי מקורות. כך המשתמשים ידעו בדיוק לאיזה שירות הם נותנים הרשאות, ותכונות כמו התראות ישויכו כראוי לכל אפליקציה.

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

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

שימוש באותו מקור

הגישה השנייה היא פיתוח האפליקציות השונות ל-PWA באותו מקור. התרחישים האלה כוללים:

נתיבים לא חופפים

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

• https://example.com/app1/
• https://example.com/app2/

נתיבים חופפים/מוטמעים

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

• https://example.com/ (ה'אפליקציה החיצונית')
• https://example.com/app/ (ה'אפליקציה הפנימית')

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

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

אתגרים במספר אפליקציות PWA מאותו מקור

ריכזנו כאן כמה בעיות מעשיות שקיימות בשתי הגישות לאותו מקור:

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

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

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

אתגרים נוספים לגבי נתיבים חופפים/מוטמעים

בעיה נוספת בגישה של נתיבים חופפים/מוטמעים (כאשר https://example.com/ היא האפליקציה החיצונית ו-https://example.com/app/ היא האפליקציה הפנימית) היא שכל כתובות ה-URL באפליקציה הפנימית ייכללו בפועל גם באפליקציה החיצונית וגם באפליקציה הפנימית.

בפועל, הבעיות הבאות עשויות להתרחש:

• קידום התקנה: אם המשתמש נכנס לאפליקציה הפנימית (לדוגמה, בדפדפן אינטרנט), כשהאפליקציה החיצונית כבר מותקנת במכשיר של המשתמש, בדפדפן לא יוצגו הבאנר לקידום ההתקנה, והאירוע BeforeInstallPrompt לא יופעל. הסיבה לכך היא שהדפדפן יבדוק אם הדף הנוכחי שייך לאפליקציה שכבר מותקנת, ויגיע למסקנה שהוא שייך לאפליקציה. הפתרון לבעיה הוא להתקין את האפליקציה הפנימית באופן ידני (דרך האפשרות 'יצירת קיצור דרך' בתפריט הדפדפן), או להתקין את האפליקציה הפנימית קודם, לפני האפליקציה החיצונית.
• Notification ו-Badging API: אם האפליקציה החיצונית מותקנת אבל האפליקציה הפנימית לא, התראות ותגים שמגיעים מהאפליקציה הפנימית יופיעו בטעות באפליקציה החיצונית (שהיא ההיקף המקיף הקרוב ביותר של אפליקציה מותקנת). התכונה הזו פועלת כראוי רק אם שתי האפליקציות מותקנות במכשיר של המשתמש.
• תיעוד קישורים: האפליקציה החיצונית עשויה לתעד כתובות URL ששייכות לאפליקציה הפנימית. הסבירות לכך גבוהה במיוחד אם האפליקציה החיצונית מותקנת אבל האפליקציה הפנימית לא. באופן דומה, קישורים באפליקציה החיצונית שמקשרים לאפליקציה הפנימית לא יקפיצו את התיעוד לאפליקציה הפנימית, כי הם נחשבים כחלק מהיקף האפליקציה החיצונית. בנוסף, ב-ChromeOS וב-Android, אם האפליקציות האלה מתווספות לחנות Play (כפעילויות אינטרנט מהימנות), האפליקציה החיצונית תתעד את כל הקישורים. גם אם האפליקציה הפנימית מותקנת, מערכת ההפעלה עדיין תציע למשתמש לפתוח אותם באפליקציה החיצונית.

סיכום

במאמר הזה התייחסנו לשיטות שונות שבהן מפתחים יכולים ליצור כמה אפליקציות Progressive Web App שקשורות זו לזו באותו דומיין.

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

• מקורות נפרדים: מומלץ
• מקור זהה, נתיבים לא חופפים: לא מומלץ
• מקור זהה, נתיבים חופפים/מוטמעים: לא מומלץ בכלל

אם אי אפשר להשתמש במקורות שונים, מומלץ מאוד להשתמש בנתיבים לא חופפים (למשל https://example.com/app1/ ו-https://example.com/app2/) במקום בנתיבים חופפים או בתצוגת עץ, כמו https://example.com/ (לאפליקציה החיצונית) ו-https://example.com/app/ (לאפליקציה הפנימית).

מקורות מידע נוספים

• אפליקציות Progressive Web Apps באתרים עם כמה מקורות

תודה רבה על הבדיקות הטכניות וההצעות: Joe Medley,‏ Dominick Ng, ‏ Alan Cutter, ‏ Daniel Murphy, ‏ Penny McLachlan, ‏ Thomas Steiner ו-Darwin Huang

צילום: Tim Mossholder ב-Unsplash