Server-Sent Events מוסבר- SSE כאלטרנטיבה ל-WebSocket¶
כשמתכנתים צריכים עדכונים בזמן אמת מהשרת - התראה חדשה, התקדמות של תהליך, תשובה שמגיעה מילה אחרי מילה כמו בצ'אטבוט - כמעט תמיד הקפיצה הראשונה במחשבה היא WebSocket. אבל יש כלי פשוט הרבה יותר שמתאים לחצי מהמקרים האלה, ורוב המתכנתים אפילו לא יודעים שהוא קיים - Server-Sent Events, או בקיצור SSE.
הבעיה עם HTTP רגיל¶
בבקשת HTTP רגילה, הדפדפן שואל שאלה והשרת עונה פעם אחת, והחיבור נסגר. אם השרת רוצה לעדכן את הדפדפן שוב אחרי כמה שניות, הוא לא יכול - הוא צריך לחכות שהדפדפן ישאל שוב. זו הסיבה שאתרים ישנים היו עושים polling - שולחים בקשה חדשה כל כמה שניות "יש חדש?" - פתרון שעובד, אבל מבזבז המון בקשות מיותרות כשאין כלום חדש.
SSE - חיבור אחד שנשאר פתוח¶
SSE פותר את זה בפתרון אלגנטי - הדפדפן פותח חיבור HTTP רגיל לשרת, אבל השרת לא סוגר אותו אחרי תשובה אחת. הוא משאיר אותו פתוח, ושולח דרכו אירועים חדשים בכל פעם שיש משהו לעדכן, בלי שהדפדפן צריך לשאול שוב. זה נראה מבחוץ כמו בקשת HTTP רגילה שנשארת "תלויה" ופשוט ממשיכה לזרום נתונים, כל עוד שני הצדדים לא סוגרים אותה.
מהצד של הדפדפן, ה-API פשוט להפליא. פותחים אובייקט EventSource עם כתובת השרת, ומאזינים לאירועים שמגיעים דרכו - כמה שורות קוד, בלי צורך בספריות חיצוניות.
אז למה לא פשוט WebSocket תמיד¶
WebSocket חזק יותר - הוא נותן תקשורת דו-כיוונית מלאה, כלומר גם הדפדפן וגם השרת יכולים לשלוח הודעות בכל רגע, ולא רק השרת. אבל הכוח הזה מגיע עם מחיר - WebSocket דורש פרוטוקול נפרד מ-HTTP, טיפול מיוחד בניתוקים והתחברות מחדש, ותשתית שרת שיודעת להחזיק חיבורים כאלה בקנה מידה.
SSE, לעומת זאת, רץ על HTTP רגיל לגמרי - מה שאומר שהוא עובד עם כל תשתית שכבר יודעת לטפל בבקשות HTTP, כולל proxies ו-load balancers רגילים, בלי הגדרות מיוחדות. הוא גם מגיע עם התחברות מחדש אוטומטית מובנית בדפדפן - אם החיבור נופל, הדפדפן מנסה להתחבר שוב לבד, בלי שאתם צריכים לכתוב שום קוד לזה.
מתי SSE מספיק ומתי צריך WebSocket¶
הכלל הפשוט - אם הזרימה של המידע היא בכיוון אחד בלבד, מהשרת לדפדפן, SSE כמעט תמיד מספיק ופשוט הרבה יותר לתחזק. התראות, עדכוני סטטוס, פיד חדשות שמתעדכן לבד, ותשובות שנבנות מילה אחרי מילה כמו בצ'אטבוטים - כל אלה בדיוק המקרה שSSE נבנה בשבילו. WebSocket נשאר הבחירה הנכונה כשצריך גם כיוון הפוך - צ'אט חי שבו כולם שולחים וגם מקבלים, משחק מרובה משתתפים, או עריכה משותפת של מסמך בזמן אמת.
למה זה מפתיע כל כך הרבה מתכנתים¶
הרבה מתכנתים בונים מערכת התראות פשוטה ומגיעים ישר ל-WebSocket, כי זה השם שהם מכירים, ומגלים אחר כך שהם השקיעו בתשתית מורכבת בהרבה ממה שבאמת נדרש. לדעת מתי הבעיה שלכם היא בעצם חד-כיוונית, ולא דו-כיוונית, זה בדיוק סוג ההחלטה שחוסכת שבועות פיתוח מיותרים.
מאיפה מתחילים לבנות עם זה¶
הבנה טובה של HTTP ואיך שרת מתקשר עם דפדפן היא הבסיס לכל אחת מהטכנולוגיות האלה, כולל SSE ו-WebSocket כאחד. בקורס צד-שרת שלנו אנחנו בונים תכונות זמן אמת אמיתיות, כולל הבנה מתי כל כלי מתאים, לא רק איך כותבים אותו.
בונים תכונה שדורשת עדכונים חיים ולא בטוחים איזה כלי מתאים? זו בדיוק השאלה שכדאי לשאול בקהילה.