למה הגישה הקלאסית נידונה לכישלון כאן
בואו נשים את זה על השולחן: סקריפט Python פשוט ששולח בקשת GET לכתובת מוצר ב-One Project יחזיר לכם מעט מאוד מידע שימושי. רוב התוכן, כולל מחירים, זמינות, תמונות ומידות, נטען דינמית באמצעות JavaScript לאחר טעינת הדף הראשונית. זה אומר שהמקור שלכם הוא לא ה-HTML הראשוני, אלא ה-DOM הסופי שמתקבל אחרי הרצת סקריפטים. כאן נכנס לתמונה הצורך בכלי שמריץ דפדפן אמיתי. תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית – מהירות, יציבות, וה-API שלו פשוט נקי יותר. כשמתחילים פרויקט איסוף קטלוג One Project, המטרה היא לא רק להביא דף, אלא לחכות לאירועי רשת ספציפיים (XHR/Fetch) שמביאים את המידע על המוצר. לפעמים המידע מגיע כ-JSON מקונן בתוך תג <script>, ולפעמים הוא תוצאה של קריאת API פנימית. צריך להשתמש ב-DevTools של הדפדפן כדי להבין את זרימת הנתונים, לא רק להסתכל על ה-HTML הסופי. אם אתם לא מוכנים לצלול לרשת ולנתח בקשות, הפרויקט הזה לא בשבילכם. המפתח הוא להבין שה-scraper שלכם הוא לא רק parser, הוא סימולטור של משתמש אמיתי.
ארכיטקטורה לאיסוף בקנה מידה: 15,000 מוצרים ויותר
אחרי שפיצחנו דף מוצר בודד, האתגר עובר לסריקת כל האתר. קטלוג האופנה של One Project מכיל אלפי מוצרים, שמתעדכנים תדיר. אנחנו מדברים על סדר גודל של 15,000-20,000 דפי מוצר, לא כולל דפי קטגוריה. סריקה סינכרונית של כמות כזו תיקח ימים. הפתרון היחיד שעובד הוא ארכיטקטורה אסינכרונית. אם אתם לא משתמשים ב-async ל-1000+ דפים, אתם מבזבזים 80% מהזמן על המתנה ל-I/O. דרישת חובה, לא nice-to-have. המערכת צריכה לכלול תור משימות (כמו RabbitMQ או Redis), ו-workers שמריצים Playwright. חשוב להגביל את קצב הבקשות מכל IP. אל תעברו את ה-20 בקשות לדקה מכתובת אחת. זה מצריך מאגר של פרוקסי איכותי. פרוקסי דאטה-סנטר זולים ייחסמו תוך שעות. צריך להשתמש בפרוטוקול שמחליף IP אוטומטית, וכאן הדיון על איך לבחור פרוקסי residential הופך להיות קריטי. המטרה היא להגיע לקצב כולל של 100-150 דפים בדקה על פני כל המערכת, מה שמאפשר סריקה מלאה של הקטלוג תוך 2-3 שעות, עם שיעור הצלחה של 98% ומעלה. זה הבסיס לכל מודיעין מתחרים One Project שרוצים לבנות.
נקודת הכשל הספציפית לאתרי אופנה: וריאציות וזמינות
הנה תרחיש שראיתי קורס פרויקטים יותר מפעם אחת: ה-scraper עובד, הוא מביא מחירים ושמות מוצרים, והכל נראה תקין. ואז, אחרי שבוע, מגלים שהנתונים על מלאי לפי מוצר שגויים לחלוטין. הבעיה באתרי אופנה כמו One Project היא המטריצה המורכבת של וריאציות: צבע, מידה, ולפעמים גם דגם. המידע הזה לא תמיד קיים בטעינה הראשונית של הדף. לעיתים קרובות, בחירת צבע מפעילה קריאת API שמחזירה את המידות הזמינות והמלאי עבור אותו צבע ספציפי. scraper נאיבי יאסוף רק את המידע של וריאציית הדיפולט. כדי לבצע מעקב מלאי/זמינות One Project בצורה נכונה, צריך לאתר את האלמנטים שמפעילים את שינוי הווריאציה (למשל, כפתורי צבע), לדמות לחיצה על כל אחד מהם, לחכות לתגובת הרשת, ורק אז לאסוף את נתוני הזמינות. זה תהליך איטי ומסורבל. הוא דורש לוגיקה מורכבת בתוך ה-scraper ויכול להכפיל או לשלש את זמן הריצה פר מוצר. זה המקום שבו פרויקטים נכשלים – לא בחסימה, אלא באיסוף דאטה שקט ולא שלם. צריך גם לשים לב לשינויים ב-UI. עדכון קטן במבנה ה-DOM של כפתורי הצבע יכול לשבור את כל הלוגיקה הזו.
מעבר לנתונים הגולמיים: בניית API ופיד נתונים
איסוף הנתונים הוא רק חצי מהעבודה. הערך האמיתי מגיע כשהופכים את המידע הגולמי למוצר שמיש. בין אם זה לצורך ניטור מחירים One Project או להזנת מערכת BI, צריך פורמט נקי ועקבי. המטרה הסופית היא בדרך כלל API / קובץ נתונים One Project שניתן לצרוך בקלות. אחרי כל סריקה, יש להריץ תהליך ניקוי וסטנדרטיזציה. לדוגמה, חילוץ מידות מספריות מטקסטים כמו "מידה: 42 (אזל המלאי)" או המרת מחירים למספרים נקיים. חשוב לשמור היסטוריית שינויים, במיוחד למחירים ולזמינות. מסד נתונים כמו PostgreSQL מתאים פה מצוין. חשוב לתכנן סכמה שתתמוך במעקב אחר שינויים ברמת הווריאציה (SKU). הייצוא הסופי יכול להיות קובץ CSV שבועי שמועלה ל-S3, או API פנימי שמספק את המידע העדכני ביותר על פי דרישה. בניית ה-API הפנימי דורשת תכנון נוסף, אבל היא מאפשרת גמישות אדירה ואינטגרציה עם מערכות אחרות בזמן אמת. חשוב לזכור שהנתונים האלה, בעיקר מפרטים טכניים של מוצרים, יכולים להגיע למאות מגה-בייטים של טקסט נקי אחרי סריקה מלאה.
מתי הגישה הזו היא Overkill (ולמה זה נדיר)
אני תמיד טוען שצריך להתחיל עם הכלים הנכונים, אבל יש מצבים שבהם שימוש ב-Playwright וארכיטקטורה מבוזרת זה כמו להביא טנק למטווח ירי באקדח אוויר. אם כל מה שאתם צריכים זה לעקוב אחרי מחיר של חמישה מוצרים ספציפיים פעם ביום, ייתכן שתוכלו להסתפק בפתרון פשוט יותר. אולי אפילו תמצאו שהמידע שאתם צריכים נמצא ב-Sitemap של האתר או בפיד RSS נסתר. עם זאת, התרחיש הזה נדיר מאוד בעולם האיקומרס התחרותי. כמעט כל use case עסקי רציני – ניטור קטגוריה שלמה, מעקב מלאי דינמי, ניתוח מבצעים – דורש את הגישה הכבדה. הבעיה בגישה המינימליסטית היא שהיא שבירה. ברגע ש-One Project ישנו משהו קטן במבנה הדף או יוסיפו הגנה בסיסית, הסקריפט הפשוט שלכם יישבר. הגישה המבוססת על דפדפן מלא, במיוחד עם כלים כמו מדריך Playwright stealth שמסווים את האוטומציה, היא הרבה יותר עמידה לשינויים. ההשקעה הראשונית במורכבות גבוהה יותר, אבל היא חוסכת שעות של תחזוקה ותיקונים בהמשך. אם אתם חושבים לטווח ארוך, אין באמת קיצורי דרך.