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

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

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

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

צילום על ידי טים מוסלדר ב-UnFlood