מעבר ל-API הפנימי: למה `requests` פשוט לא יספיק
האינסטינקט הראשון של כל מהנדס הוא לפתוח את ה-DevTools, ללכת לטאב ה-Network ולמצוא את קריאות ה-API שמביאות את המידע על המוצרים. ב-Quik, הגישה הזו תחשוף בפניכם רשת של endpoints שמספקים JSON נקי. זה נראה כמו ניצחון קל. הבעיה היא שהקריאות האלה כמעט תמיד מאובטחות. זה יכול להיות token ב-header שמתחדש כל כמה דקות, פרמטרים שדורשים חישוב בצד הלקוח, או בדיקה של טביעת אצבע של הדפדפן. ניסיון לשחזר את הלוגיקה הזו ידנית הוא קרב אבוד מראש. גם אם תצליחו היום, שינוי קטן בקוד של האתר מחר ישבור לכם את הכל. זו הסיבה שגישה המבוססת על שליחת בקשות HTTP ישירות נידונה לכישלון בפרויקטים ארוכי טווח מול אתרים כאלה. המורכבות בתחזוקה פשוט לא שווה את זה. במקום לבזבז שבועות על הנדסה לאחור, עדיף להשקיע את הזמן בבניית תשתית שתדמה משתמש אמיתי. זה אולי נראה כמו מאמץ גדול יותר בהתחלה, אבל זה מה שמבדיל בין פרויקט חד-פעמי למערכת דאטה אמינה. לכן, אנחנו אפילו לא מתחילים עם requests.
Playwright במקום Selenium: ארכיטקטורה לאיסוף קטלוג מלא
תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד במהירות, יציבות ויכולות ניהול רשת. כשמדובר על איסוף קטלוג Quik המונה כ-25,000 מוצרים, יעילות היא שם המשחק. המטרה היא לאסוף את כל המוצרים, כולל שדות כמו שמות מוצרים וקטגוריות, בצורה מהירה ואמינה. הארכיטקטורה שאני מעדיף מתבססת על Playwright עם הגדרות stealth מתקדמות כדי להיראות כמו משתמש אמיתי. אנחנו לא מפעילים דפדפן מלא לכל בקשה. במקום זאת, אנחנו מריצים תהליך עובד (worker) שמנהל תור של כתובות URL (קטגוריות ומוצרים). כל worker משתמש ב-instance בודד של דפדפן כדי לעבד עשרות או מאות דפים, מה שמצמצם משמעותית את ה-overhead. חשוב מאוד לחסום טעינה של משאבים לא רלוונטיים כמו תמונות, פונטים ו-scripts של מעקב. עם Playwright, אפשר לעשות את זה בקלות עם page.route. פעולה זו לבדה יכולה לקצץ 50-70% מזמן טעינת העמוד ולהקטין את צריכת רוחב הפס. במקום לגרד את ה-HTML, אנחנו יכולים ליירט את תגובות ה-API ישירות מהדפדפן, מה שנותן לנו את ה-JSON הנקי בלי להתמודד עם parsing מסורבל.
התרחיש שבו הכל נופל: זמינות לפי סניף
הנה failure mode קלאסי באתרים כמו Quik: אתה בונה scraper מושלם, מריץ אותו על כל הקטלוג, ואוסף מחירים ומלאי. הכל נראה תקין. ואז אתה מגלה שהנתונים שאספת רלוונטיים רק לסניף ברירת המחדל של תל אביב, בזמן שהעסק שלך צריך נתונים מהסניף בחיפה. אתרי סופרמרקט אונליין מציגים זמינות ומבצעים שונים בהתאם למיקום המשתמש או לסניף המשלוח שנבחר. המידע הזה נשמר בדרך כלל ב-cookie או ב-localStorage. אם ה-scraper שלך לא מנהל את הסשן בצורה נכונה ולא מגדיר את המיקום הרצוי לפני תחילת הריצה, אתה אוסף דאטה שגוי. זה לא שגיאת 403 או CAPTCHA, זה כישלון שקט ומסוכן. הפתרון דורש הבנה של התהליך: צריך לנווט תחילה לעמוד בחירת הסניף, לבצע את הפעולה הנדרשת (לחיצה על כפתור, שליחת טופס), ורק אז להתחיל את ה-crawl. בנוסף, כל worker בתהליך ה-scraping חייב להשתמש בפרופיל דפדפן נפרד (browser context) עם ה-cookies וה-storage המתאימים כדי להבטיח בידוד מלא בין סשנים של סניפים שונים. בלי זה, אתם פשוט אוספים זבל.
ניטור מחירים בקנה מידה: פרוקסי, קצב וטיפול בשגיאות
ברגע שיש לנו את הקטלוג המלא, השלב הבא הוא ניטור מחירים Quik באופן שוטף. כאן המשחק משתנה מאיסוף חד-פעמי לפעולה מתמשכת. המטרה היא לזהות שינויי מחיר ומבצעים כמה שיותר קרוב לזמן אמת. זה דורש ריצות תכופות על עשרות אלפי עמודי מוצר. הפעלה של 30,000 בקשות ממכונה אחת תוך שעה היא דרך בטוחה להיחסם. לכן, בחירת שירות פרוקסי אמין היא קריטית. אני ממליץ על רשת residential proxies איכותית המאפשרת rotation של כתובות IP בכל בקשה או כל כמה דקות. קצב הבקשות צריך להיות מנוהל בזהירות. אנחנו לא רוצים להפציץ את השרתים של Quik. קצב של 20-30 בקשות מקבילות, מפוזרות על פני מאות כתובות IP, הוא נקודת פתיחה טובה. המטרה היא להגיע לכיסוי מלא של הקטלוג תוך שעות בודדות, לא דקות. שגיאות הן חלק בלתי נפרד מהתהליך. צריך לטפל באופן ספציפי בשגיאות 429 (Too Many Requests) על ידי הפחתת הקצב באופן דינמי, ובשגיאות 5xx על ידי ניסיון חוזר עם backoff אקספוננציאלי. כל בקשה שנכשלת צריכה לחזור לתור לניסיון נוסף. רק כך אפשר לשאוף לאחוזי הצלחה של מעל 98%.
השלב האחרון: הפיכת הדאטה הגולמי ל-API שימושי
איסוף הנתונים הוא רק חצי מהעבודה. דאטה גולמי שיושב במסד נתונים הוא לא שימושי עד שהוא נגיש. השלב הסופי הוא לספק את המידע הזה בצורה שקל לצרוך אותה, בין אם זה עבור מודיעין מתחרים Quik או להזנת מערכות פנימיות. הדרך הנכונה לעשות זאת היא לחשוף את הנתונים דרך API / קובץ נתונים פנימי. אנחנו בונים שכבת API פשוטה מעל מסד הנתונים של ה-scraping. ה-API הזה מאפשר לשאול שאלות כמו: 'מה המחיר הנוכחי של מוצר X?', 'הצג לי את כל המוצרים בקטגוריה Y שהמלאי שלהם השתנה היום', או 'יצא לי את כל המבצעים החדשים כקובץ CSV'. זה הופך את תוצרי ה-scraping לנכס אמיתי לארגון. חשוב לכלול ב-API גם מטא-דאטה על תהליך האיסוף עצמו: מתי כל פריט מידע נאסף לאחרונה (timestamp), מאיזה מקור (URL), והאם האיסוף האחרון הצליח. השקיפות הזו בונה אמון בנתונים ומאפשרת למשתמשי הקצה להבין את מגבלות המידע שהם צורכים. בסופו של דבר, המטרה היא לא רק לאסוף דפים, אלא לספק תובנות.