איי שרת ב־Astro: רינדור מושהה רק של החלקים הדרושים בדף סטטי

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

1. להבחין בין המסמך הראשוני לאזור שמגיע מאוחר יותר

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

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

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

2. לתכנן גם את fallback כחלק מתצוגה שלמה

הדוגמה הקטנה הבאה מציגה את אופן השימוש. ההנחה היא שהרכיב UserDelivery והמתאם כבר מומשו בנפרד.

---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
  <p slot="fallback">פרטי כתובת המשלוח נבדקים כעת.</p>
</UserDelivery>

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

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

3. לשמור על גבולות נתונים מצומצמים

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

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

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

4. לקבוע את מדיניות המטמון לפי קהל התצוגה

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

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

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

5. לבדוק תחילה חיבור איטי וכישלון

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

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

6. להשוות את התועלת לפני ואחרי באותם תנאים

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

ככל שהשאלה לבחירת מועמד ל־server island ממוקדת יותר, כך היא מועילה יותר. השאלה ״האם אפשר לקרוא את ההקדמה לספר לפני שהמידע הזה מגיע?״ מסייעת להחלטת המימוש יותר מהשאלה ״האם האתר הזה סטטי?״. בדקו את סביבת הפריסה לצד מדריך הרינדור לפי דרישה של Astro, ואז התחילו מאזור אישי קטן אחד ואמתו את ההתנהגות עד למצבי כישלון אמיתיים.