אדריכלות

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

SPA לעומת MPA

כיום יש שתי תבניות ארכיטקטוניות עיקריות בפיתוח אתרים: אפליקציות עם דף יחיד, או SPA, ואפליקציות עם כמה דפים, או MPA.

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

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

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

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

אפליקציות בדף יחיד

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

אפליקציות בדף יחיד מתאימות לארכיטקטורה אם:

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

שירותי SPA לא מתאימים לארכיטקטורה אם:

  • ביצועי הטעינה הראשונית הם קריטיים. בדרך כלל, שירותי SPA צריכים לטעון יותר JavaScript כדי לקבוע מה לטעון ואיך להציג אותם. זמן הניתוח והביצוע של קוד ה-JavaScript הזה, בשילוב עם אחזור תוכן, איטי יותר משליחת HTML שעבר עיבוד.
  • האפליקציה פועלת בעיקר במכשירים שרמת הטעינה שלהם נמוכה עד ממוצעת. מאחר ששירותי SPA תלויים ב-JavaScript לעיבוד, חוויית המשתמש תלויה באופן משמעותי בעוצמה של המכשיר הספציפי שלהם מאשר ב-MPA.

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

אפליקציות עם כמה דפים

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

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

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

MPA לא יכול להיות בחירה טובה לארכיטקטורה אם:

  • פעולות כמו הורדה מחדש, ניתוח מחדש והפעלה מחדש של JavaScript או CSS הם פעולות יקרות מאוד. ב-PWA אפשר לצמצם את הבעיה הזאת באמצעות קובצי שירות (service worker).
  • הקשר בצד הלקוח, כמו מיקום המשתמש, לא עובר בצורה חלקה בין התצוגות, והשגת ההקשר מחדש עשויה להיות יקרה. צריך לתעד ולאחזר את הנתונים, או לבקש אותם מחדש בין התצוגות.

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

באיזה מהם לבחור?

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

לא משנה איזו בחירה לבחור, השלב הבא הוא להבין איך להשתמש ב-Service Workers בצורה הטובה ביותר כדי לספק את החוויה הטובה ביותר.

כוחו של Service Worker

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

קובץ השירות כולל (SWI)

קובצי שירות (SWI) כוללים את אחד מהדפוסים החדשים של שימוש ב-Service Workers כחלק בלתי נפרד מארכיטקטורת אתר. SWI מחלק נכסים נפרדים, בדרך כלל דף HTML, לחלקים בהתאם לצורכי השמירה במטמון שלהם, ואז מחבר אותם יחד ב-Service Worker כדי לשפר את העקביות, הביצועים והאמינות, תוך צמצום גודל המטמון. אתר עם כותרת עליונה גלובלית, אזור תוכן, סרגל צד וכותרת תחתונה.

התמונה הזו היא דוגמה לדף אינטרנט. הוא כולל חמישה קטעים שונים שמחלקים את הדף ל:

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

פריסה כוללת

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

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

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

CSS ו-JavaScript

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

אזור תוכן

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

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

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

התנסות עצמית

כדי לנסות את ה-Service Worker כולל ב-codelab הבא:

הצגת התשובות באופן שוטף

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

היא עושה זאת כי:

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

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

העבודה עם Streams API יכולה להיות מאתגרת כי היא מורכבת וברמה נמוכה. למרבה המזל, יש מודול של תיבת עבודה שיכול לעזור בהגדרת תגובות סטרימינג ל-Service Workers.

היקף ההרשאות של דומיינים, מקורות ו-PWA

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

מדיניות מקור זהה

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

לדוגמה: ל-https://squoosh.app ול-https://squoosh.app/v2 יש מקור זהה, אבל ל-http://squoosh.app, ל-https://squoosh.com, ל-https://app.squoosh.app ול-https://squoosh.app:8080 יש מקורות שונים. מידע נוסף ודוגמאות זמינים בחומר העזר בנושא MDN של מדיניות המקור הזהה.

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

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

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

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

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

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

משאבים