מי שבנה אי פעם אפליקציית פייתון בענן מכיר את הרגע שבו צריך לבצע בדיקה קטנה על כותרת או להפנות נתיב ישן, ומוצא את עצמו מעיר שרת כבד רק בשביל להחזיר הפניה. אתמול הודיעה Vercel על עדכון שפותר את הנקודה הזאת: תמיכה רשמית בכתיבת Routing Middleware בפייתון. המהלך מיועד למפתחים שמריצים שירותים מבוססי FastAPI, Flask או Django ורוצים לטפל בבקשות לפני שהן מגיעות אל השרת המרכזי.
זה שינוי מבורך. הוא חוסך כאב ראש מיותר.
פייתון לפני השרת הראשי
הרעיון מאחורי Routing Middleware אינו חדש בעולמות ה-Node, אך כעת הוא מתרחב למפתחי פייתון תחת מודל fluid compute של החברה. מדובר בשכבת יירוט שרצה לפני שהבקשה פוגשת את ה-Cache או מועברת לשרת הראשי. היא מאפשרת לשכתב כתובות, לבצע הפניות מיידיות או להחזיר תגובה סופית מבלי להפעיל את מלוא הלוגיקה העסקית של היישום.
You can now write routing middleware in Python for FastAPI, Flask, Django, and other Python frameworks. It runs before requests reach your app, and can rewrite, redirect, or answer them.ההכרזה הרשמית של Vercel
בדוקומנטציה של Vercel מובהר כי המידוולוור שלכם רץ כאפליקציית ASGI או WSGI עצמאית ומבודדת לגמרי. כדי להפעיל אותו, מפנים את מאפיין ה-proxy בקובץ ההגדרות אל נקודת הכניסה. ההגדרה נתמכת הן בקובץ vercel.json והן בקובץ vercel.toml, כאשר שני הפורמטים תומכים באותם מאפיינים בדיוק. המידוולוור חייב להשתמש באותו סביבת ריצה כמו היישום הראשי, אחרת תהליך הבנייה ייכשל עם שגיאת proxy_runtime_mismatch.
פרידה מ־requirements.txt
כדי להבטיח זמני עלייה מינימליים ולמנוע צווארי בקבוק, ורסל אינה טוענת את כל החבילות של האפליקציה המרכזית לתוך תהליך הניתוב. המשמעות המיידית היא שינוי תפיסתי בניהול התלויות בפרויקט: שימוש בקובץ requirements.txt פשוט כבר לא יספיק כאן. פרויקטים שרוצים להפעיל מידוולוור בפייתון יידרשו לעבור לקובץ pyproject.toml ולהגדיר קבוצת תלויות נפרדת. בקבוצה זו, הנקראת vercel.proxy, מגדירים אך ורק את החבילות הנחוצות לניתוב, ובראשן הספרייה הייעודית vercel-proxy.
ההתקנה המומלצת בדוקומנטציה מתבצעת באמצעות מנהל החבילות uv בפקודה uv add --group vercel.proxy vercel-proxy. אם המידוולוור ייבא ספרייה שלא הוגדרה במפורש תחת קבוצה זו, הבקשות אליו ייכשלו בזמן אמת. הארכיטקטורה המבודדת אמנם מונעת סרבול מיותר, אך מציבה רף הגירה ברור לפרויקטים ישנים שעדיין נשענים על ניהול חבילות שטוח.
קוד מול הגדרות CDN
לא כל בעיית ניתוב מצדיקה הרצת פונקציית פייתון חיה. בתיעוד הרשמי מדגישים כי אם לוגיקת הניתוב אינה דורשת קוד מותאם אישית, יש להעדיף קונפיגורציה סטטית ישירות בקובץ JSON של הפרויקט. חוקים סטטיים עבור הפניות, שכתוב נתיבים או שינוי כותרות רצים ישירות על גבי רשת ה-CDN ללא הפעלת קוד חי, ולכן הם מהירים יותר ואינם גוזלים משאבי מחשוב.
הסכנה הגדולה בהפעלת מידוולוור היא שחרורו לרשת ללא הגדרת matcher קפדנית. ללא הגדרה זו, פונקציית הפייתון תרוץ על כל בקשה בודדת שמגיעה לדומיין, כולל תמונות, קובצי CSS ונכסים סטטיים. מצב זה מוסיף השהיה מיותרת לכל קריאה ועלול לגרור חיובים בלתי צפויים בחשבון החודשי שלכם. עבור סטארטאפים בישראל הבדיקה הזו קריטית במיוחד, שכן שרתי המחשוב המרכזיים אינם ממוקמים בארץ, וריצה מיותרת עלולה להגדיל את ה-latency.
לא הייתי ממהר להרים פרוקסי בלי סינון כזה.
| תרחיש שימוש | הפתרון המומלץ | מיקום הריצה | השפעה על עלות וזמני תגובה |
|---|---|---|---|
| הפניות פשוטות ושכתוב נתיבים | הגדרות סטטיות ב-vercel.json | שכבת ה-CDN | מהיר ביותר, ללא עלות ריצה נוספת |
| הוספה או הסרה של כותרות קבועות | הגדרות transforms סטטיות | שכבת ה-CDN | ללא השפעה על זמני מעבד או זיכרון |
| לוגיקה מותנית לפי עוגיות או שאילתות | תנאי has ו-missing בקונפיגורציה | שכבת ה-CDN | תגובה מיידית ברמת הרשת |
| אימות טוקנים, A/B טסטינג וניתוב דינמי | Routing Middleware בקוד פייתון | סביבת Fluid Compute מבודדת | עלות ריצה לפונקציה וזמני עיבוד נוספים |
מבט מהיר על הקוד
העבודה עם החבילה החדשה נשענת על מחלקת Proxy שמנתבת נתיבים בדומה לפריימוורקים מודרניים. המודל מתבסס על אובייקט Request שמגיע מ-Starlette, ומאפשר גישה מהירה לכותרות, נתיבים ופרמטרים. בנוסף, Vercel מזריקה לכל בקשה כותרות מיקום גאוגרפיות כגון x-vercel-ip-country ו-x-vercel-ip-city, מה שמאפשר לבצע ניתובים מבוססי מדינה בקלות רבה ישירות מהקוד.
תשובות המידוולוור נחלקות לפי המטרה: שימוש ב-ContinueResponse מאפשר לבקשה להמשיך ליישום המרכזי תוך הזרקת כותרות נוספות, בעוד ש-RewriteResponse מנתב אותה ליעד אחר באופן שקוף לקליינט. אם תרצו לחסום גישה או להחזיר תוכן מידי, תוכלו להשיב ב-JSONResponse או ב-Response רגיל. בקשות שאינן תואמות לאף נתיב שהוגדר ממשיכות כברירת מחדל הלאה לאפליקציה הראשית.
בינתיים, מי שבונה ב-Next.js או Astro ימשיך להשתמש במנגנונים המובנים שלו ולא יצטרך את שכבת ה-proxy הזו. אבל למי שמריץ שירותי API בפייתון על ורסל, מדובר בתוספת כוח משמעותית, בתנאי שלא תשכחו להגדיר סינון לנתיבים.
מקורות
- Routing Middleware now supports Pythonhttps://vercel.com/changelog/routing-middleware-now-supports-python
- Routing Middlewarehttps://vercel.com/docs/routing-middleware
- Routing Middleware: Python Referencehttps://vercel.com/docs/routing-middleware/python-reference
- Djangohttps://weba.co.il/tools/django/
- FastAPIhttps://weba.co.il/tools/fastapi/
- Vercelhttps://weba.co.il/tools/vercel/
- JSONhttps://weba.co.il/glossary/json/
הידיעה נכתבה מהמקורות שלמעלה בתאריך הפרסום, וכל טענה בה נבדקה מולם. מצאתם טעות? כתבו.