למה הגישה הקלאסית נידונה לכישלון כאן
הטעות הראשונה שרוב המהנדסים עושים היא להתייחס לאתר כמו יינות ביתן כאל מסמך סטטי. הם מריצים cURL, מקבלים 200 OK, וחושבים שהם בדרך הנכונה. אבל ה-HTML שהם מקבלים הוא רק קונטיינר ריק. כל התוכן — מוצרים, קטגוריות, מחירים, מבצעים — נטען מאוחר יותר באמצעות JavaScript שמבצע קריאות XHR/Fetch ל-endpoints של API פנימי. לכן, כל ניסיון לפרסר את התגובה הראשונית יחזיר אפס נתונים.
כאן נכנס לתמונה כלי כמו Playwright. לא, תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים וב-API האסינכרוני שלו. הוא מאפשר לנו להריץ דפדפן אמיתי (headless, כמובן), לתת ל-JavaScript של האתר לרוץ, וליירט את אותן קריאות API פנימיות. זו הגישה הנכונה. במקום לפרסר HTML מבולגן ומשתנה, אנחנו מכוונים ישירות למקור הנתונים המובנה שהאתר עצמו צורך. זה לא רק יותר יציב, זה גם הרבה יותר מהיר מרינדור מלא של כל דף ודף.
בניית קטלוג מלא: מיפוי קטגוריות ואיסוף מוצרים
המשימה הראשונה בכל פרויקט כזה היא איסוף קטלוג יינות ביתן המלא. זה הבסיס לכל דבר אחר. התהליך מתחיל במיפוי היררכיית הקטגוריות. לרוב, יש endpoint API ייעודי שמחזיר את עץ הקטגוריות כולו. צריך לאתר אותו דרך ה-Developer Tools של הדפדפן. אחרי שיש לנו את כל מזהי הקטגוריות, אנחנו יכולים להתחיל לעבור עליהן אחת-אחת ולשלוף את המוצרים.
באתר בסדר גודל של יינות ביתן, אנחנו מדברים על אלפי, ולפעמים עשרות אלפי מוצרים. אי אפשר לעשות את זה באופן סינכרוני. אם אתה לא משתמש ב-async ל-10,000+ דפים, אתה מבזבז 80% מהזמן על המתנה ל-IO. הפעולה הזו דורשת תכנון. צריך לבנות לוגיקת pagination חכמה, לטפל במקרים של קטגוריות ריקות, ולהיות מוכנים לכך שמבנה התגובה יכול להשתנות מעט בין קטגוריות שונות. השדות החשובים בשלב זה הם שמות מוצרים, מק"טים (SKUs), תיאורים, ותמונות. את הנתונים הדינמיים יותר, כמו מחירים ומבצעים, נאסוף בתהליך נפרד ובתדירות גבוהה יותר.
שכבת הזמן-אמת: ניטור מחירים ומעקב מלאי
כאן נמצא הערך האמיתי עבור רוב ה-use cases. ניטור מחירים יינות ביתן ומעקב מלאי/זמינות יינות ביתן דורשים גישה שונה מאיסוף הקטלוג הראשוני. הנתונים האלה משתנים לעיתים קרובות, והם לרוב תלויי-הקשר — למשל, תלויים בסניף שנבחר. תרחיש כשל נפוץ הוא איסוף מחירים בלי להגדיר את ה-cookie או ה-header הנכון של הסניף, מה שמוביל לקבלת נתונים לא רלוונטיים או מחירי ברירת מחדל.
הפתרון הוא לזהות את קריאות ה-API הספציפיות שמעדכנות מחיר ומלאי. לרוב זו תהיה קריאת POST עם רשימת מק"טים. המטרה היא להגיע למצב שבו אנחנו יכולים לשלוח בקשות ישירות ל-endpoint הזה, עם מינימום overhead. כשזה עובד, אפשר להגיע לקצבים של מאות מוצרים בשנייה ממכונה אחת, עם latency ממוצע של מתחת ל-700ms לבקשה. המטרה היא לשמור על אחוז הצלחה של מעל 98%, וזה דורש טיפול בשגיאות 429 ו-5xx בצורה אלגנטית. בלי זה, ה-scraper שלכם יפול אחרי כמה דקות של עבודה אינטנסיבית.
מתי הגישה הזו לא מספיקה (ומה עושים אז)
חשוב להבין, הגישה של יירוט קריאות API פנימיות לא חסינה לגמרי. היא עובדת מצוין עד לרגע שהאתר מחליט להוסיף שכבת הגנה רצינית יותר. אם מתחילים לראות אתגרים של Cloudflare או CAPTCHAs של Akamai בתגובות ה-API, זה סימן שהם זיהו את התעבורה שלנו כחשודה. זה קורה בדרך כלל כשמנסים לבצע מודיעין מתחרים יינות ביתן בקנה מידה גדול מאוד, עם אלפי בקשות בדקה מכתובת IP בודדת.
במצב כזה, יירוט API פשוט כבר לא יספיק. נצטרך לחזור להשתמש בדפדפן מלא דרך Playwright, אבל הפעם עם שכבות התגנבות. זה המקום שבו מדריך Playwright stealth הופך להיות קריטי. נצטרך להשתמש בטביעות אצבע של דפדפנים אמיתיים, לטפל ב-cookies בצורה מתוחכמת יותר, ובעיקר, להשתמש בשירותי פרוקסי איכותיים. אם אתם רציניים לגבי scale, תצטרכו להבין איך לבחור פרוקסי residential כדי לפזר את הבקשות שלכם על פני מאות או אלפי כתובות שונות. המורכבות עולה משמעותית, וזה trade-off שצריך לקחת בחשבון.
השלב הסופי: הפיכת הנתונים ל-API נקי ושימושי
איסוף הנתונים הוא רק חצי מהעבודה. אם התוצר הסופי הוא תיקייה מלאה בקבצי JSON מבולגנים, לא עשינו כלום. המטרה הסופית של רוב הפרויקטים האלה היא ליצור API / קובץ נתונים יינות ביתן שיהיה קל ונוח לצריכה על ידי מערכות אחרות. זה אומר לבנות תהליך ETL (Extract, Transform, Load) שמנרמל את הנתונים הגולמיים.
התהליך הזה כולל ניקוי שמות מוצרים, תיקון קטגוריות, המרת מחירים למבנה אחיד, ומעקב אחרי היסטוריית שינויים. לדוגמה, חשוב לשמור לא רק את המחיר הנוכחי, אלא גם את המחיר הקודם ותאריך השינוי. התוצר הסופי צריך להיות נקודת קצה של API או ייצוא CSV/API יומי או שבועי שכל אחד בארגון יכול להשתמש בו בלי להבין את המורכבות של ה-scraping עצמו. זה השלב שהופך פרויקט טכני חד-פעמי לנכס דאטה אסטרטגי. אם לא מתכננים את השלב הזה מההתחלה, סביר להניח שהפרויקט ייכשל תחת משקל המורכבות של עצמו תוך כמה חודשים.