יצירה של כמה אפליקציות מסוג 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.

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

מומלץ להימנע משימוש במקורות שונים בחלקי אתר של אותו אתר כשמנסים ליצור אפליקציית אינטרנט מאוחדת מסוג Progresive Web App.

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

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

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

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

אם רוצים להשתמש באותו שם דומיין בכולם, אפשר להשתמש בתת-דומיינים. לדוגמה, חברה שמספקת כמה אפליקציות או שירותים באינטרנט יכולה לארח אפליקציית אימייל בכתובת 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 באותו מקור. התרחישים האלה כוללים:

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

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

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

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

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

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

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

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

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

אתגרים במספר אפליקציות 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