אחד הלקוחות שלנו הגיע עם דרישה שכללה בתוכה בעיה, או כמו שאנחנו אוהבים לקרוא לזה – אתגר. הלקוח רצה להציג מידע מאתר אחר באתר שלו. הוא קיבל את האישורים הנדרשים מבעלי האתר וכששאל איך עושים את זה, לא קיבל תשובה ברורה. בתור התחלה, ניסינו להבין האם לאתר יש API שמאפשר לקרוא ממנו מידע ונענינו בשלילה. בהתאם, היינו צריכים למצוא פתרון שיאפשר לנו לקרוא את המידע ללא API.
מטרות
- להציג מידע מאתר אחר באתר של הלקוח
- לעקוף את המגבלה שנוצרת עקב היעדר API באתר ממנו קוראים את המידע
- ליצור סקרייפר עם פייתון וסלניום
- לשמור את המידע במאגר הנתונים של האתר של הלקוח על מנות לצמצם זמני ריצה של הלמבדה כדי לחסוך עלויות – מעין תהליך קאש (Cache)
- שיפור זמני טכינה על ידי קריאת המידה ממאגר הנתונים באתר של הלקוח במידה וכבר חיפשו בעבר
תהליך הפיתוח
כפי שכבר ציינו, הלקוח רצה להציג מידע מאתר אחר באתר שלו אך הייתה לו מגבלה. לאתר ממנו רצה למשוך את המידע, לא היה API שיאפשר לקרוא את המידע ולהציג באתר של הלקוח. על מנת לפתור את האתגר הזה, בנינו סקרייפר (Scraper) בעזרת שימוש בפייתון וסלניום (Python and Selenium) שאיחסנו על למבדה (Lambda) של AWS שמופעלת על ידי קריאת API. זה איפשר לנו לקרוא את המידע ולקבל אותו כתגובה לבקשה מהאתר של הלקוח שבוא רצינו להציג את המידע.
תחילה, הפיתוח נעשה באופן לוקאלי על מנת לזרז ולהקל על הבנייה של הסקרייפר וגם כדי לחסוך עלויות ב- AWS. מטרת הסקרייפר היא להציג תוצאות חיפוש מאתר אחר באתר של הלקוח. על כן, הסקרייפר ידע לקבל מילות חיפוש באופן דינאמי, לפנות לאתר ממנו רוצים לקרוא את הנתונים, לבצע את החיפוש, לקרוא את התוצאות ולהחזיר אותן כתגובה לבקשת API בעזרת Json.
כשסיימנו את הפיתוח של הסקרייפר עצמו ולאחר שעשינו לו בדיקות, איחסנו אותו בלמבדה של AWS והגדרנו לו כתובת על מנת שנוכל לפנות אליו ולקבל ממנו את ה- Json שהוא מחזיר.
עכשיו הגיע השלב שבו אנחנו מחברים אותו בפועל לאתר. בסביבת הפיתוח של האתר (כי לא עובדים בסביבת פרודקשן), פיתחנו, בקוד כמובן, את החלק שלוקח את מילות החיפוש שהמשתמש הכניס באתר של הלקוח ופונה לסקרייפר שבנינו על מנת לקבל ממנו את המידע. ברגע שהסקרייפר החזיר תשובה, האתר שומר את הנתונים שחזרו במאגר הנתונים ומציג אותם ללקוח.
המידע הנשמר במאגר הנתונים של האתר, מאפשר לנו לדעת לאילו מילות חיפוש כבר קיימות התוצאות באתר ומתי הפעם האחרונה שהתבצעה פנייה עבור אותן מילות חיפוש לסקרייפר. ככה, יצרנו מנגנון קאש שמאפשר לחסוך פניות לסקרייפר ובעצם כך לצמצם עלויות ב- AWS וגם לשפר את מהירות התגובה באתר של הלקוח. זה קורה היות ופנייה לסקרייפר לוקחת זמן, עד שהסקרייפר עצמו מסיים לרוץ.
בעזרת המידע הזה, יצרנו מנגנון קאש שמתנקה באופן אוטומטי כל 30 ימים. כלומר, ברגע שמשתמש חיפש הגדרה מסוימת, כל עוד לא עברו 30 ימים מאז קריאת המידע האחרונה מהסקרייפר עבור אותה הגדרה, המידע ייקרא ממאגר הנתונים של האתר של הלקוח. במידה ועברו 30 ימים או יותר, תתבצע פנייה חדשה לסקרייפר והאתר יעדכן את המידע הקיים אצלו עבור אותה הגדרת חיפוש למידע החדש שהגיע לעוד 30 ימים.
תוצאה
לאחר הטמעת הסקרייפר באתר הלקוח, תהליך קריאת המידע מהאתר ללא ה- API עבד בהצלחה ובצורה שלא מורגשת למשתמש באתר של הלקוח מלבד זמני טעינה בעת חיפוש מילות חיפוש חדשות. כפי שאמרנו, עבור מילות חיפוש שכבר חיפשו לפני כן באתר, אין צורך לפנות לסקרייפר. על ידי שימוש בפייתון וסלניום, הצלחנו לעקוף את המגבלה של היעדר API וקריאת המידע מהאתר למרות המגבלה הזו.
בנוסף, יצרנו באתר של הלקוח מערכת קאש שאיפשרה לנו לשפר את חוויית המשתמש בעת חיפוש באתר של הלקוח. ולא רק זה, יצירת מערכת הקאש איפשרה לנו גם לצמצם משמעותית את כמות הפניות ללמבדה המאוחסנת ב- AWS מה שצימצם משמעותית גם עלויות ריצה שלה.
סיכונים
לקריאת מידע מאתרים אחרים בעזרת סקרייפר יש מספר סיכונים שצריך לשים עליהם דגש לפני שמתחילים פרויקט כזה. אחד הסיכונים הגדולים ביותר בפרויקט כזה הוא האיסור של אתרים מסויימים על קריאת המידע מהם באמצעות סקרייפרים ובוטים. במקרים כאלה של קריאת המידע ללא אישור מפורש של בעלי האתר בכתב, אנחנו יכולים לחשוף את עצמינו לתביעה משפטית שכן אנחנו מפירים זכויות יוצרים.
יתרה מכך, קריאת מידע מאתרים בעזרת סקרייפרים שאין להם API, עשויה להפר את הסכם השימוש שלהם. על מנת לצמצם את הסיכון כמה שיותר, חשוב לקבל אישור מפורש בכתב של בעלי האתר ממנו אנחנו רוצים לקרוא את המידע בעזרת סקרייפר לפני שאנחנו בכלל מתחילים לעבוד על הפרויקט.
סיכון נוסף שצריך לקחת בחשבון הוא האפשרות שהאתר ממנו אנחנו רוצים לקרוא את המידע עלול לחסום אותנו. כיום, יש אתרים ומערכות שיודעים לזהות בוטים וסקרייפרים על ידי פעולות מהירות מאוד, אופן השימוש וכו’, כמו למשל קאפצ’ה. על מנת להתגבר על זה, חשוב להגביל את הקצב של הבוט או הסקרייפר על מנת לנסות לדמות התנהגות אדם. בנוסף, הטמעת פעולות רנדומליות, כמו למשל זמן ההמתנה בין קליקים, שינוי ה- user agent ועוד, אנחנו יכולים לצמצם את הסיכוי שהבוט או הסקרייפר שלנו יזוהה ככזה ולפעמים אפילו למנוע את זה לחלוטין.
בפרויקט הזה, ביצענו צעדים על מנת לצמצם את הסיכונים הנ”ל על ידי קבלת האישורים הנחוצים מבעלי האתר ממנו קראנו את המידע. מה שאיפשר לנו לא רק לבצע את הפרויקט ללא דאגה לצד המשפטי אלא גם ללא חשש שהאתר ממנו קראנו את המידע ייחסום את הסקרייפר שבנינו ללקוח. בסוף כל שלב ביצענו בדיקות שהכל עובד כמו שצריך ורק לאחר שראינו שאכן כך, עברנו לשלב הבא. בנוסף, כל העבודה התבצעה על סביבת פיתוח ורק לאחר סיום העבודה כולה, הועברה לסביבת פרודקשן. כך למעשה, יכולנו לעבוד ולפתח ללא חשש ליצירת שגיאות באתר שכן זו סביבת פיתוח, הלקוח בינתיים יכול היה להמשיך לבצע פעולות באתר שלו כמו למשל העלאת תכנים, עדכונים וכו’ ללא חשש.
לסיכום
על ידי בניית הסקרייפר בעזרת פייתון וסלניום, הצלחנו להתגבר על המגבלה של היעדר API באתר ממנו רצינו לקרוא מידע על מנת להציג באתר של הלקוח שלנו. הטמענו בהצלחה מנגנון קאש שתורם גם לחווית המשתמש מבחינת זמני טעינה וגם מוזיל עלויות ב- AWS ללקוח.
בעזרת קבלת האישורים הנחוצים ויצירת סביבת פיתוח, הצלחנו למזער המון סיכונים ולצמצם משמעותית (כמעט לאפס) את כמות התקלות והבעיות המשפטיות והטכניות שיכלו היו להיווצר במידה ולא היינו עושים את הדברים האלה.
