ניתוב בצד לקוח מול צד שרת - מה ההבדל בפועל¶
לוחצים על קישור באתר, והדף כאילו "מהבהב" לרגע ונטען מחדש מהתחלה. באתר אחר, לוחצים על קישור דומה, וההחלפה קורית בצורה חלקה כמעט בלי שמרגישים אותה. ההבדל הזה נובע ממנגנון שנקרא ניתוב, routing, וכדאי להבין איך הוא עובד לפני שבוחרים ארכיטקטורה לפרויקט הבא שלכם.
רגע, זה לא אותו דבר כמו רינדור¶
לפני שממשיכים, חשוב להבהיר בלבול נפוץ. יש כבר פוסט על רינדור בצד שרת מול צד לקוח שמדבר על שאלה אחרת לגמרי - איפה ה-HTML של דף מסוים נוצר, בשרת מראש או בדפדפן של המשתמש. זו שאלה על מקור התוכן.
הפוסט הזה עוסק בציר שונה לחלוטין - ניתוב, כלומר איך הדפדפן עובר בין כתובות URL שונות אחרי שהדף הראשוני כבר נטען. זו שאלה על מנגנון הניווט, לא על מקור ה-HTML. אפשר בהחלט לשלב את שני הצירים בדרכים שונות, למשל אתר עם רינדור בצד שרת שמשתמש בניתוב בצד לקוח לאחר הטעינה הראשונית, וזה בדיוק מה שקורה בהרבה פריימוורקים מודרניים. חשוב פשוט לזכור שמדובר בשתי שאלות נפרדות שנוטים לבלבל ביניהן.
איך ניתוב בצד שרת עובד - המודל הקלאסי¶
במודל המסורתי, שנקרא לפעמים אתר רב עמודי, כל קישור באתר מצביע על כתובת שמייצגת דף שלם. כשלוחצים על קישור, הדפדפן שולח בקשת HTTP חדשה לגמרי לשרת. השרת מעבד את הבקשה, בונה עמוד HTML מלא, ושולח אותו בחזרה. הדפדפן זורק את כל מה שהיה על המסך קודם, וטוען את העמוד החדש מאפס.
זה בדיוק הרגע ה"מהבהב" שהזכרנו בהתחלה. הוא קורה כי כל הדף, כולל קבצי ה-CSS וה-JavaScript, נטען מחדש בכל ניווט. המודל הזה פשוט מאוד להבנה ולתחזוקה, ועובד מצוין גם בלי JavaScript בכלל, אבל המחיר הוא טעינה מלאה בכל לחיצה על קישור.
איך ניתוב בצד לקוח עובד - מודל האפליקציה החד עמודית¶
במודל החד עמודי, single page application, קוד JavaScript שרץ בדפדפן מיירט את הלחיצה על הקישור לפני שהיא הופכת לבקשת רשת רגילה. במקום לתת לדפדפן לשלוח בקשה חדשה לשרת, ספריית ניתוב בצד לקוח משנה את הכתובת שמוצגת בשורת הכתובות, ומחליפה רק את הרכיבים הרלוונטיים על המסך - למשל את תוכן העמוד המרכזי, בלי לגעת בתפריט העליון או בפוטר שכבר שם.
התוצאה מבחינת המשתמש היא מעבר חלק, כמעט מיידי, בין "עמודים" שבפועל הם רק החלפות של רכיבים בתוך אותו דף HTML יחיד שנטען פעם אחת בהתחלה.
מה זה History API ואיך הוא מאפשר את הקסם¶
הדבר שמאפשר לניתוב בצד לקוח לעבוד בלי לשבור את שורת הכתובות ואת כפתורי קדימה ואחורה של הדפדפן הוא ממשק שנקרא History API. הוא מאפשר לקוד JavaScript לשנות את הכתובת המוצגת בשורת הכתובות, ולהוסיף רשומה חדשה להיסטוריית הדפדפן, בלי לגרום בפועל לטעינה מחדש של הדף.
בזכות זה, כשמשתמש לוחץ על כפתור "אחורה", הדפדפן יודע לאיזו כתובת לחזור, וספריית הניתוב בצד לקוח מקשיבה לשינוי הזה ומעדכנת את הרכיבים המוצגים בהתאם, בלי טעינה חדשה מהשרת. זה מה שיוצר את התחושה של אפליקציה אמיתית ולא רק אוסף של דפים נפרדים.
היתרונות והחסרונות של כל גישה¶
ניתוב בצד לקוח מרגיש מהיר מאוד אחרי שהעמוד הראשוני נטען, כי אין יותר טעינה מלאה בכל ניווט. הבעיה היא שהוא דורש להוריד כמות משמעותית של JavaScript מראש כדי שהמנגנון הזה יעבוד בכלל, מה שמאט את הטעינה הראשונית. בעבר היו לו גם אתגרי קידום אורגני, כי מנועי חיפוש התקשו לנתח תוכן שנבנה כולו על ידי JavaScript, אם כי הרבה מהאתגרים האלה השתפרו עם השנים.
ניתוב בצד שרת פשוט יותר להבנה, עובד גם כש-JavaScript כבוי או נכשל, ולא דורש הורדה מקדימה של קוד ניתוב מורכב. המחיר הוא טעינה מלאה, כולל הבהוב ואיפוס מצב, בכל לחיצה על קישור, מה שמרגיש הרבה פחות זריז באפליקציות אינטראקטיביות.
בפועל, רוב האתרים המודרניים בוחרים גישה משולבת שמנסה לקחת את הטוב משני העולמות, אבל להבין את שני המנגנונים הבסיסיים הוא הבסיס להבנת כל שילוב מתקדם יותר. בקורס צד לקוח בונים את ההבנה הזו צעד אחר צעד, כולל תרגול מעשי של ניתוב בצד לקוח בכלים אמיתיים.
לסיכום¶
ניתוב בצד שרת וניתוב בצד לקוח הם שני מנגנונים שונים לפתרון אותה בעיה - איך לעבור בין כתובות שונות באתר. הראשון פשוט ואמין אבל כרוך בטעינה מלאה בכל פעם, השני חלק ומהיר אחרי הטעינה הראשונית אבל דורש יותר JavaScript מראש. חשוב לזכור שזו שאלה נפרדת לגמרי משאלת הרינדור, גם אם קל לבלבל ביניהן.
יש לכם שאלות על ניתוב באפליקציה שאתם בונים? נשמח לעזור בדיסקורד.