למה requests.get הוא בזבוז זמן מוחלט
בואו נשים את זה על השולחן: אם הגישה הראשונית שלכם ל-Wolt Israel היא requests.get, אתם בדרך הלא נכונה. הורדת ה-HTML הראשוני מהשרת תחזיר לכם מעטפת ריקה כמעט לחלוטין, שלד של אפליקציית React או Vue עם תג <div id="root"> ותו לא. כל התוכן — מסעדות, תפריטים, מחירים, זמינות — נטען באופן דינמי דרך עשרות קריאות XHR/Fetch לרשת ה-API הפנימית שלהם. אפשר, תיאורטית, לנסות לעשות reverse engineering לקריאות האלה. ביליתי לילות בדיבאגר של Chrome בניסיון למפות את ה-endpoints, להבין את ה-headers הנדרשים, ולפענח את ה-tokens. הבעיה היא שהמבנה הזה שביר בכוונה. ה-API משתנה, מתווספים פרמטרים חדשים, וה-authentication logic יכול להיות מורכב. כל שינוי קטן בצד הלקוח שלהם ישבור לכם את ה-scraper וישלח אתכם חזרה לשולחן השרטוט. הפתרון היציב יותר, גם אם הוא דורש יותר משאבים, הוא להשתמש בכלי שמריץ דפדפן מלא. תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים וב-API האסינכרוני שלו. הוא מאפשר לנו לעבוד עם האתר כפי שמשתמש אמיתי היה עובד, בלי לנחש את הלוגיקה הפנימית של ה-API.
ארכיטקטורת Scraper לאיסוף קטלוג וניטור מחירים
אז החלטנו על Playwright. איך נראה תהליך עבודה טיפוסי? המטרה הראשונה היא בדרך כלל איסוף קטלוג Wolt Israel מלא. זה מתחיל בניווט לעמוד הראשי, אבל כאן מגיע האתגר הראשון: התוכן תלוי מיקום. כדי לראות את המסעדות הנכונות, צריך להזין כתובת או לתת הרשאות מיקום. הפתרון הוא להשתמש ב-proxies הממוקמים באזורים הגיאוגרפיים הרלוונטיים. זה קריטי. שימוש ב-proxy מפרנקפורט כדי לגשת לתוכן של תל אביב ייתן תוצאות שגויות או חלקיות. ה-flow הנכון הוא: אתחול דפדפן עם proxy ישראלי, ניווט לאתר, הגדרת כתובת ספציפית, ורק אז התחלת הגלישה. לאחר שהגענו לרשימת המסעדות, אנחנו מתמודדים עם infinite scroll. צריך לדמות גלילה של משתמש, להמתין לטעינת אלמנטים חדשים (למשל, באמצעות page.waitForSelector על רכיב חדש ברשימה), ולאסוף את הקישורים. משם, נכנסים לכל מסעדה בנפרד ומחלצים את התפריט. כאן אפשר לחלץ שמות מוצרים/מודעות ומחירים. עבור ניטור מחירים ב-Wolt Israel, התהליך חוזר על עצמו באופן דורי, כאשר בכל ריצה אנחנו משווים את הנתונים החדשים לבסיס הנתונים הקיים ומזהים שינויים. קצב של 10-15 בקשות לדקה פר IP הוא סביר כדי לא לעורר חשד, אבל זה דורש ניהול proxy pool איכותי כדי להגיע להיקפים גדולים.
תרחיש הכשל הנפוץ: חסימות מבוססות התנהגות
באתרים כמו Wolt Israel, חסימות הן לא רק עניין של IP. הן מבוססות התנהגות. ראיתי scrapers נופלים לא כי ה-proxy שלהם נשרף, אלא כי הדפדפן האוטומטי שלהם צרח "אני בוט". תרחיש כשל קלאסי הוא ניווט מהיר מדי. משתמש אנושי לא טוען עמוד מסעדה, מחלץ את כל המידע ב-500 מילישניות, וקופץ מיד למסעדה הבאה, 24/7. המערכות שלהם מזהות את זה. הן עוקבות אחר תנועות עכבר, אירועי גלילה, וקצב האינטראקציה. אם ה-scraper שלכם פשוט מבצע קליקים וניווטים סדרתיים בלי הפסקות אקראיות ובלי לדמות התנהגות אנושית, הוא יקבל CAPTCHA או חסימה מוחלטת. כ-30% מהכישלונות בפרויקטים כאלה נובעים מ-fingerprinting של הדפדפן. כדי להתמודד עם זה, חובה להשתמש בפתרונות stealth. ספריית playwright-extra עם הפלאגין stealth היא נקודת התחלה מצוינת. היא מטפלת בהסתרת מאפיינים של דפדפן אוטומטי כמו navigator.webdriver. בלי זה, אתם פשוט מרימים דגל אדום ענק בכל בקשה. זה לא עניין של אם תיחסמו, אלא מתי. וזה בדרך כלל קורה בשעה 3 לפנות בוקר, כשהדאטה היומי צריך להיות מוכן.
מעקב מלאי ומודיעין מתחרים: מה אפשר ללמוד מהנתונים
מעבר למחירים וקטלוגים, הנתונים מ-Wolt Israel מאפשרים שני מקרי שימוש מתקדמים. הראשון הוא מעקב מלאי/זמינות Wolt Israel. על ידי סריקה תדירה של תפריטים, אפשר לזהות מתי פריטים מסוימים הופכים ל"לא זמינים זמנית". המידע הזה הוא זהב עבור מסעדות מתחרות או ספקים. אם מסעדה פופולרית נתקעת בלי חומר גלם מסוים בכל יום חמישי בערב, זו הזדמנות עסקית. המידע הזה קיים ב-DOM, לרוב כ-class שונה על פריט התפריט או כטקסט מפורש. ה-scraper צריך להיות בנוי לחפש את האינדיקטורים האלה באופן ספציפי. המקרה השני הוא מודיעין מתחרים Wolt Israel. אפשר לעקוב אחרי שינויים בתפריטים, הוספת מנות חדשות, שינויי מחירים אסטרטגיים, והשקת מבצעים. בניית דשבורד שמציג את הפעילות של 10-20 מסעדות מפתח באזור מסוים יכולה לספק תובנות אדירות. האתגר הטכני כאן הוא לא רק האיסוף, אלא גם ה-structuring של הדאטה. צריך לבנות מזהה ייחודי לכל פריט תפריט (למשל, שילוב של שם המסעדה ושם הפריט) כדי שניתן יהיה לעקוב אחריו לאורך זמן. בלי primary key יציב, ניתוח היסטורי הופך לסיוט.
מתי לא כדאי לבנות Scraper כזה בעצמך
אחרי כל מה שאמרתי, חשוב להיות ריאליים. יש מצבים שבהם בניית scraper מורכב ל-Wolt Israel היא פשוט לא ההחלטה הנכונה. אם הצורך שלכם הוא חד-פעמי, למשל, API / קובץ נתונים Wolt Israel שאתם צריכים פעם אחת בלבד, המאמץ ההנדסי הנדרש לבניית מערכת יציבה כנראה לא מצדיק את עצמו. פיתוח, בדיקה ותחזוקה של scraper כזה דורשים עשרות שעות עבודה של מהנדס מנוסה. המורכבות של ניהול proxies גיאוגרפיים, התמודדות עם CAPTCHAs, וטיפול בשינויים תכופים במבנה האתר היא משמעותית. אם אתם צוות קטן או שאין לכם מומחיות ספציפית ב-web scraping, המשאבים שלכם ינוצלו טוב יותר במקומות אחרים. בנוסף, אם אתם צריכים נתונים עם רמת אמינות של 99.9% ו-latency נמוך, מערכת שבניתם בעצמכם תתקשה לעמוד בזה בלי השקעה רצינית בתשתיות וניטור. לפעמים, הפתרון הנכון הוא לא לבנות, אלא למצוא דרך אחרת להשיג את הדאטה. זה לא כישלון, זו החלטה הנדסית נבונה שמכירה ב-trade-offs.