מערך שיעור: Middleware Pipeline

משך: 2 שעות אקדמיות (90 דקות).

מטרת השיעור: הסטודנטים יבינו שכל בקשה עוברת שרשרת שכבות מסודרת, ויכתבו Middleware בסיסי משלהם.

בסוף השיעור הסטודנטים צריכים: לרשום Middleware עם app.Use, להסביר את תפקיד next(), ולעצור שרשרת Middleware בתנאי (כמו הרשאה חסרה).

דגש קריטי: קשרו במפורש ל-SRP/OCP מיחידת ה-SOLID — זה לא נושא חדש לגמרי, זה יישום קונקרטי של עקרונות מוכרים.

מהלך השיעור#

דגשים להעברת השיעור#

• הדגמה חיה עם Console.WriteLine לפני ואחרי next() בכל Middleware עוזרת מאוד להמחיש את “שרשרת” הריצה — לא רק “שכבות” מופשטות, אלא סדר ריצה ממשי וניתן-למעקב.
• ודאו שסטודנטים מבינים בבירור: שכחת next() היא הבאג הכי נפוץ בנושא הזה — כדאי להראות אותו בכוונה (בקשה שנתקעת ולעולם לא מגיעה ל-endpoint).
• אל תתקדמו ל-Controllers (השיעור הבא) לפני שהמושג Pipeline מבוסס — Controllers הם רק “עוד תחנה” בפייפליין הזה, לא נושא נפרד.

מושגים#

Middleware — רכיב שרץ על כל בקשה, יכול לבדוק/לשנות ולהעביר הלאה. Pipeline — שרשרת מלאה של Middleware, בסדר הרישום. next() — מעביר לשכבה הבאה; בלעדיו הבקשה נעצרת.

תרגיל חשיבה#

שאלת פתיחה: “אם תרשמו Middleware של בדיקת הרשאה אחרי Middleware שמבצע לוגיקה עסקית כלשהי (למשל שמירה למסד נתונים) — מה יכול להשתבש?”

מהלך: הובילו לתובנה חמורה: פעולה עסקית (כמו כתיבה למסד נתונים) עלולה לקרות לפני שבכלל בדקו שהמשתמש מורשה לבצע אותה — פרצת אבטחה ממשית, לא רק “סדר לא-אופטימלי”. זו בדיוק הסיבה שסדר Middleware הוא החלטת עיצוב קריטית, לא פרט טכני שולי.

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