למה בקשות GET פשוטות נכשלות מול ims.gov.il
האינסטינקט הראשון של כל מהנדס הוא לשלוח בקשת GET עם requests ולנתח את ה-HTML עם BeautifulSoup. זה עובד על 90% מהאתרים הפשוטים. אבל כאן, הגישה הזו תוביל אתכם למבוי סתום. הבעיה היא לאו דווקא JavaScript מורכב, אלא האופן שבו השרת מנהל סשנים ומגיש את הנתונים. לעיתים קרובות, נתונים קריטיים כמו טמפרטורה או תחזית גשם לא נטענים ב-HTML הראשוני. הם מגיעים דרך קריאות XHR/Fetch אסינכרוניות שמתבצעות לאחר טעינת הדף, ודורשות cookies או headers ספציפיים שנוצרו על ידי סקריפט בצד הלקוח.
ניסיון לחקות את הקריאות האלה ידנית הוא משחק של חתול ועכבר. אולי תצליחו לבודד את ה-endpoint הנכון, אבל אז תגלו שהוא דורש טוקן שפג תוקף אחרי 15 דקות, או שהוא מוגן על ידי בדיקת user-agent בסיסית שתפיל כל סקריפט שלא מחקה דפדפן אמיתי. ראיתי את זה קורה: ה-scraper עובד נהדר על המחשב המקומי, אבל ברגע שהוא רץ על שרת בענן עם IP של דאטה סנטר, הוא מתחיל לקבל תגובות ריקות או דפי שגיאה. זהו ה-failure scenario הקלאסי באתרים ממשלתיים: לא חסימה אקטיבית, אלא שרשרת תלות שקטה בין רכיבים בצד הלקוח.
בניית Scraper יציב עם Playwright: הגישה הנכונה
תפסיקו לבזבז זמן על הנדסה הפוכה של קריאות רשת. ב-2025, אם אתם לא מתמודדים עם מיליוני דפים ביום, headless browser הוא הפתרון היעיל ביותר. Playwright מנצח כאן. הוא מאפשר לנו לדמות התנהגות משתמש אמיתית, מה שמבטיח שכל הסקריפטים בצד הלקוח ירוצו והנתונים יוצגו בדיוק כפי שהם מוצגים למשתמש. עבור איסוף קטלוג שלם של תחזיות, למשל איסוף נתונים מ-50 ערים מרכזיות, זה הכרחי.
התהליך פשוט: מנווטים לעמוד התחזית, ממתינים לסלקטור ספציפי שמכיל את נתוני הטמפרטורה (למשל, div.forecast-table), ורק אז מחלצים את ה-HTML. זה פותר 95% מהבעיות. יתרון נוסף הוא היכולת לטפל באינטראקציות. אם צריך ללחוץ על כפתור כדי לעבור לתחזית של 10 ימים, Playwright עושה את זה בשורת קוד אחת. זה חוסך שעות של דיבאגינג מול ה-DevTools. כמובן, זה בא עם עלות מסוימת בביצועים – כל דף דורש 2-3 שניות טעינה מלאה, לעומת עשרות מילישניות בבקשת requests. אבל העלות הזו מתגמדת מול היציבות ושיעור ההצלחה שמתקרב ל-99%. למי שרוצה לקחת את זה צעד קדימה, כדאי לחקור את היכולות המתקדמות יותר במדריך כמו מדריך Playwright stealth כדי להיראות אפילו יותר אנושיים.
מעקב אחר שינויים וזמינות נתונים בזמן אמת
אחד ה-use cases המרכזיים ל-scraping של השירות המטאורולוגי הוא לא איסוף חד-פעמי, אלא ניטור רציף. למשל, פרויקט שדורש מעקב אחר שינויים בתחזית הגשם או מעקב מלאי/זמינות של נתוני מכ"ם עדכניים. כאן, היעילות הופכת לגורם קריטי. להריץ 200 מופעים של Playwright כל 5 דקות זה בזבוז משאבים. הפתרון הוא גישה היברידית.
משתמשים ב-Playwright פעם אחת כדי לבצע לוגין (אם נדרש) ולאסוף את ה-cookies וה-headers הדרושים לסשן. לאחר מכן, שומרים אותם ומשתמשים בספריית requests עם ה-session object כדי לבצע קריאות ישירות ל-API הפנימי שהדפדפן חשף. כך מקבלים את הטוב משני העולמות: היכולת לעבור את האימות הראשוני והמורכב, יחד עם המהירות של קריאות HTTP ישירות. גישה זו מאפשרת לנו לבדוק זמינות של דוחות חדשים בקצב של עשרות בקשות בשנייה, תוך שאנחנו מוודאים שכל ה-מפרטים הטכניים (כמו לחות, מהירות רוח) נאספים בצורה מדויקת. חשוב רק לזכור לרענן את הסשן כל כמה שעות כדי למנוע חסימה.
ניהול Proxies ו-Rate Limiting: איך לא להיחסם
אתר השירות המטאורולוגי אולי לא מפעיל מערכות אנטי-בוט מהשורה הראשונה, אבל הוא בהחלט מנטר נפחי תעבורה. שליחת 5,000 בקשות מ-IP בודד תוך דקה היא דרך בטוחה לקבל שגיאות 429 (Too Many Requests) או אפילו חסימת IP זמנית. זה קריטי במיוחד כשמנסים לייצר API / קובץ נתונים השירות המטאורולוגי פרטי על בסיס הנתונים שלהם.
הפתרון הוא proxy rotation. אבל לא כל פרוקסי מתאים. פרוקסים של דאטה סנטר הם זולים ומהירים, אבל קל לזהות ולחסום אותם. לרוב, הם יספיקו לאתר הזה, כל עוד אתם מפעילים pool של לפחות 50-100 כתובות IP ומחליפים אותן בתדירות גבוהה. הגדירו rate limit בצד הלקוח שלכם: לא יותר מ-30-40 בקשות לדקה פר IP. זה נשמע איטי, אבל עם 100 כתובות IP במקביל, אתם מגיעים לקצב של מעל 3,000 בקשות בדקה, שזה די והותר לרוב היישומים. אם אתם עדיין נתקלים בחסימות, ייתכן שתצטרכו לשקול שימוש בפתרון מתקדם יותר. הבנת ה-trade-offs בין סוגי הפרוקסי השונים היא מיומנות ליבה, וכדאי לקרוא על איך לבחור פרוקסי residential כדי להבין מתי קפיצת המדרגה הזו נדרשת.
מתי Scraping הוא לא הפתרון הנכון (כן, יש מקרים כאלה)
למרות כל מה שאמרתי, יש מצבים שבהם scraping הוא פשוט לא הדרך. זהו ה-counter argument. אם כל מה שאתם צריכים זו תחזית יומית פשוטה לעיר אחת, בניית ותחזוקת scraper היא over-engineering. ישנם שירותי API מסחריים (וגם חינמיים) למזג אוויר שיספקו לכם את המידע הזה בצורה אמינה יותר ובמאמץ פיתוח אפסי. המורכבות של תחזוקת scraper – טיפול בשינויי HTML, ניהול פרוקסים, לוגיקת retries – לא תמיד מצדיקה את התוצאה.
בנוסף, חשוב לבדוק אם קיים ערוץ נתונים רשמי. אתרים ממשלתיים רבים, כולל השירות המטאורולוגי, מציעים לעיתים גישה לקבצי נתונים גולמיים או ערוצי FTP לחוקרים או לגופים ציבוריים. לפני שאתם כותבים שורת קוד אחת, חפשו עמודים כמו "מידע לציבור", "נתונים פתוחים" או "API". גישה כזו, אם קיימת, תהיה תמיד יציבה, מהירה וחוקית יותר מכל scraper שתבנו. Scraping הוא כלי רב עוצמה, אבל הוא פטיש. לא כל בעיה היא מסמר.