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

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

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

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

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

• ‫Domain: כל רצף של תוויות כפי שמוגדר במערכת שמות הדומיין (DNS). לדוגמה: com ו-example.com הם דומיינים.
• שם מארח: רשומת DNS שמפוענחת לכתובת IP אחת לפחות. לדוגמה: www.example.com הוא שם מארח, example.com יכול להיות שם מארח אם יש לו כתובת IP, ו-com אף פעם לא יזוהה ככתובת IP ולכן הוא לא יכול להיות שם מארח.
• מקור: שילוב של סכמה, שם מארח (hostname) ויציאה (port) (אופציונלי). לדוגמה, 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 של קובץ השירות (service worker) ופורמט המניפסט מאפשרים לבצע את הפעולות שצוינו למעלה באמצעות הגדרת היקף ברמת הנתיב. עם זאת, בשני המקרים, שימוש באותו מקור יוצר הרבה בעיות ומגבלות, שהשורש שלהן נובע מהעובדה שהדפדפן לא יתייחס אליהם כאילו הם 'אפליקציות' נפרדות, ולכן לא מומלץ להשתמש בגישה הזו.

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

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

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

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

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

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

אתגרים נוספים בנתיבים חופפים או מקוננים

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

בפועל, זה גורם לבעיות הבאות:

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

סיכום

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

לסיכום, אנחנו ממליצים מאוד להשתמש במקור אחר (למשל, באמצעות תת-דומיינים) כדי לארח אפליקציות 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