مراجعة Crawlee: صفحة Quotes to Scrape أعطت 0 عبر HTTP و10 داخل Chromium

ما يخلّي Crawlee عمليًا جدًا هو أن تنسيق الزحف فيه يدعم بنفس الوقت تحليل HTTP وتشغيل المتصفح. يعني الصفحة نفسها ممكن تعطيك نتائج مختلفة تمامًا حسب نوع الزاحف اللي تختاره وحسب شرط الجاهزية اللي تحدده.

في صفحة Quotes to Scrape JS العامة، CheerioCrawler رجّع 0 من الاقتباسات المستهدفة، بينما PlaywrightCrawler رجّع 10 بعد ما انتظر ظهور .quote. دورة حياة الزحف نفسها كانت متشابهة، لكن الموضوع ما كان مجرد تبديل بسيط بين صنف وآخر: معالج Cheerio استخدم $، بينما معالج Playwright اعتمد على page، وانتظار صريح، واستخراج من جهة المتصفح.

ما هو Crawlee فعليًا

Crawlee (مشروع apify/crawlee، الإصدار 3.17.0) هو مكتبة لاستخراج بيانات الويب وأتمتة المتصفح لـ Node.js وTypeScript. وهو يدعم الزحف عبر HTTP باستخدام Cheerio أو JSDOM، وكذلك الزحف عبر المتصفح باستخدام Playwright أو Puppeteer. المشروع مرخّص تحت Apache-2.0؛ لذلك راجع متطلبات الإشعار ونسب الحقوق قبل أي إعادة توزيع.

الفكرة الأساسية اللي لازم تفهمها هي الفصل بين “جلب الصفحة” و“قراءة الصفحة”. أحد المسارين يحمّل HTML الخام وما ينفّذ JavaScript. أما المسار الثاني فيشغّل Chromium ويقدر ينفذ سكربتات الصفحة، لكنه مع ذلك يحتاج إلى شرط جاهزية مناسب، وقد يفوّت المحتوى المرتبط بالتفاعل، أو المحتوى الذي يُحمَّل عند الطلب، أو Shadow DOM، أو البيانات التي فشل استدعاء API الخاص بها، أو المحتوى المحجوب بسبب البوتات. Crawlee يوفّر مفاهيم دورة حياة متطابقة عبر هذين المسارين، وليس عناصر DOM قابلة للتبديل بشكل مباشر.

وهذي هي النقطة اللي تستحق الفهم قبل ما تكتب أول selector، لأن اختيارك بين هذين المحركين هو اللي يحدد هل الـ scraper بيرجع بيانات فعلًا أو بيرجع فاضي على موقع معيّن.

أهم المزايا: محركان وواجهة API واحدة

CheerioCrawler يجلب HTML ويحلله باستخدام Cheerio؛ أما PlaywrightCrawler فيتحكم في Chromium ويقدر يلتقط لقطات شاشة. كلاهما يستخدم requestHandler، ويعرض run()، ويشترك في مفاهيم الزحف مثل الطوابير واكتشاف الروابط. لكن سياقات المعالجات تختلف: مسار Cheerio اللي تم اختباره استخرج عبر $، بينما استخدم مسار المتصفح page وwaitForSelector و$$eval. قد تبقى بنية الطابور ودورة الحياة مألوفة، لكن منطق الاستخراج نفسه قد يحتاج تكييف أو إعادة كتابة.

وتحت هذا السطح، Crawlee يوفّر البنية الأساسية اللي يحتاجها أي زحف حقيقي. فـ RequestQueue يدير قائمة عناوين URL المراد زيارتها، ويمنع التكرار، ويتتبع ما تم إنجازه. كما أن enqueueLinks يكتشف عناوين URL الجديدة ويضيفها إلى الطابور (مع إمكانية التصفية عبر selector والاقتصار على نفس النطاق) حتى يتمكن الزحف من التوسع تلقائيًا. أما Dataset فيجمع السجلات اللي تستخرجها لتصديرها لاحقًا. وبشكل افتراضي، يحفظ Crawlee كل هذا في مجلد محلي storage/ على القرص — وهذا مريح إذا تبغى تستكمل لاحقًا، لكنه ممكن يفاجئك أول مرة لما تلاقي مجلد storage/ ظهر داخل مشروعك من غير ما تطلبه. في هذا الاختبار، وجهته إلى مجلد مؤقت وعطّلت الاستمرارية عشان تظل بيئة الاختبار نظيفة.

هذي المكونات مو مبهرة بحد ذاتها، لكن الفكرة إنها مشتركة بين المحركين، يعني الطابور، واكتشاف الروابط، وDataset كلها تتصرف بالطريقة نفسها سواء كنت تزحف عبر HTTP أو عبر متصفح. أنت تتعلم واجهة API واحدة وتحصل على استراتيجيتين للجلب.

الإعداد: المتصفح الذي يجب تثبيته بشكل منفصل

التركيب اللي تم اختباره ما كان يحتوي على ملف Chromium تنفيذي بعد تثبيت الحزم.

npm install crawlee playwright اشتغل عندي بدون مشاكل — 85 حزمة، و0 ثغرات، ومن دون تعقيد. إذا وقفت هنا وشغّلت CheerioCrawler فكل شيء يمشي، لأن الزحف عبر HTTP ما يحتاج متصفح.

لكن في هذي البيئة، كان لازم تثبيت Chromium بشكل منفصل عبر npx playwright install chromium; ومن دونه فشل PlaywrightCrawler في الإقلاع. وكان الحجم المرصود للمتصفح حوالي 82 MiB، لكن الملاحظات الأصلية ما تحسم هل الرقم هذا يمثل حجم النقل أو الحجم على القرص. هذه ملاحظة خاصة بإعداد جهاز معيّن، وليست سمة ثابتة للمنتج. كذلك مسارات التوثيق وسلوك الحزم قد تتغير، لذلك هذا المقال ما يدّعي إن هذا النقص عام أو غير موثق بشكل دائم.

لذلك خلك على إعداد من خطوتين كما اختبرته: ثبّت حزم Node أولًا، ثم ثبّت المتصفح اللي يستخدمه مسار Playwright. وبرضه راجع تعليمات الإعداد الحالية لكل من Crawlee وPlaywright بحسب النسخة والمنصة اللي بتنشر عليها.

تجربة عملية: الصفحة نفسها بإجابتين مختلفتين تمامًا

الاختبار الأساسي أرسل نفس الصفحة المولدة عبر JavaScript إلى كلا الزاحفين. كان عنوان URL والحقول المستهدفة نفس الشيء؛ لكن أدوات الاستخراج ما كانت نفسها.

في النسخة المحلية، رجّع CheerioCrawler 0 من بطاقات العناصر المستهدفة لأنها ما كانت موجودة في HTML الخام. أما PlaywrightCrawler فانتظر #dynamic-products article.product-card ثم رجّع كل البطاقات 8 المتوقعة والتقط صورة شاشة. وهذي النتيجة تثبت إن العناصر المحددة كانت مكتملة في النسخة المختبرة بعد الانتظار؛ لكنها ما تعني إن المتصفح يشوف كل حالة ممكنة من الصفحة. الملفات الخام ولقطة الشاشة موجودة في مستودع القياس.

في صفحة Quotes to Scrape JS العامة، وجد CheerioCrawler 0 من الاقتباسات المستهدفة، بينما انتظر PlaywrightCrawler ظهور .quote قبل ما يستخرج 10. وهذا يؤكد نفس الفارق بين HTTP والمتصفح على هدف عام، مع اختلاف الصنف، وسياق المعالج، وشرط الانتظار، وأداة الاستخراج بين الجانبين.

والخلاصة المفيدة هنا أضيق من كذا: تحقّق من الحقول المطلوبة بعد مسار HTTP، ثم انتقل إلى زاحف متصفح لما الرد الخام ما يرجّع هذي الحقول. ومعالج المتصفح نفسه لازم ينتظر شرطًا مرتبطًا بهذه الحقول.

كما أن مسار HTTP رجّع كل السجلات المتوقعة على فهارس وعينات مقالات ثابتة ومضبوطة، وفكّ ترميز ثمانية عناصر متوقعة من رد JSON مباشر، وتجوّل في رسم بياني محدود من 11 صفحة، وحوّل استجابة 500 واحدة إلى failedRequestHandler. هذي فحوص منفصلة للقدرة، وليست درجة دقة واحدة. وعلى صفحة Books to Scrape العامة، رجّع الـ selector المُعدّ 20 منتجًا كفحص سريع.

تقدر تلاقي الأوقات الكاملة والأرقام التفصيلية لكل اختبار في results/crawlee-test-summary.json.

والآن لازم نكون واضحين في التحفظات، لأن نجاح تشغيل واحد وعلى جهاز واحد له حدوده، وما راح أجمّل هذي الحقيقة. هذي أزمنة تشغيل وليست Benchmarks — جهاز واحد، وتشغيل واحد لكل اختبار، لذلك تعامل مع الكلفة الأعلى لكل صفحة في مسار المتصفح على إنها “أبطأ بشكل واضح من تشغيل Cheerio اللي ينتهي في أقل من ثانية”، وليس رقمًا رسميًا منشورًا. وفيه أيضًا أشياء ما اختبرتها في هذي الجولة: تدوير البروكسي، وأحواض الجلسات، والتشغيل واسع النطاق من مئات إلى آلاف الصفحات، واستمرارية RequestQueue والاستئناف بعد التعطل، ومحرك Puppeteer، وسهولة تصدير Dataset وKeyValueStore (أنا كتبت التصدير يدويًا هنا). أقدر أؤكد قصة المحركين ودقة مستوى النسخة التجريبية. لكن ما أقدر أؤكد قابلية التوسع أو مقاومة الحظر، وما راح أدّعيها.

ما هو المشترك وما الذي يجب تغييره

الواجهة المشتركة هي تنسيق الزحف. كلا الصنفين يقبلان requestHandler ويعرضان run(). ويمكن تنظيم الطوابير، وبيانات الطلب، واكتشاف الروابط، وخطافات الفشل، ومفاهيم التخزين بشكل متسق حول أي من مساري التنفيذ. وهذا يقلل كمية البنية التحتية اللي يحتاج الفريق يعيد تعلمها لما يكون الهدف يحتاج متصفح.

لكن واجهة الوصول إلى الصفحة مو مشتركة. فمعالج CheerioCrawler يحصل على وصول قائم على Cheerio مثل $، ويقدر يتعامل مع نص الاستجابة من دون متصفح. أما معالج PlaywrightCrawler اللي تم اختباره هنا فيتلقى page; وينتظر selector ثم يجري التقييم داخل DOM الخاص بالمتصفح. وحتى لو أصدر المعالجان نفس مخطط السجل، فهما يوصلان له عبر واجهات مختلفة. وممكن محول (adapter) قابل لإعادة الاستخدام يخفي جزءًا من هذا الاختلاف، لكن هذا الاختبار ما نفذ أو عرض مثل هذا المحول.

وهذا الفرق مهم عند التقدير. فاستبدال صنف الزاحف قد يحافظ على الطابور، وDataset، وسياسة عناوين URL، لكن الـ selectors، وفحوص الجاهزية، ولقطات الشاشة، وخطوات التفاعل، والتعامل مع الأخطاء قد تتغير كلها. لذلك يعامل المقال “بنية الزحف المشتركة” على إنها الفائدة اللي تم التحقق منها، ويرفض فكرة “الترحيل بخط واحد” على إنها وعد غير مدعوم.

مسار عملي لاختيار المحرك

ابدأ بمسار HTTP أولًا عندما يحتوي HTML المعاد أو رد JSON مباشر على الحقول المطلوبة. عرّف شرط اكتمال — مفاتيح مطلوبة، أو حدًا أدنى لعدد العناصر، أو selector مستهدف — وفشّل التنفيذ بوضوح إذا ما تحقق ذلك. فالمصفوفة الفارغة ليست دليلًا على أن الصفحة بلا بيانات؛ ففي حالتي JavaScript هنا، كانت تعني أن التمثيل المختار ما فيه العناصر المستهدفة.

وانقل الفشل المعرّف نوعيًا إلى معالج متصفح لما يصير التنفيذ ضروريًا. في هذا الاختبار، انتظرت الصفحة المحلية #dynamic-products article.product-card، بينما انتظرت صفحة الاقتباسات العامة .quote. هذه الشروط جزء من عقدة الاستخراج. أما حدث التحميل العام ما يثبت إن بيانات التطبيق وصلت فعلًا، وهذي التجربة ما تدعم قاعدة انتظار عالمية.

وبعد الانتقال إلى المتصفح، حافظ على ثبات مخطط الإخراج حتى لو اختلفت أدوات DOM. سجّل أي محرك أنتج النتيجة، وأي شرط جاهزية تحقق، وما إذا كان التحقق من الحقول المطلوبة نجح. كذا يصير الرجوع من HTTP إلى المتصفح قابل للملاحظة بدل ما يتحول بصمت إلى سجلات تبدو مقبولة رغم نقص الحقول.

وأخيرًا، تعامل مع تثبيت المتصفح وكلفته التشغيلية كمدخلات نشر. فملاحظة الـ 82 MiB مفيدة فقط كقيمة تقريبية محلية؛ لذلك قِس النسخة الدقيقة من المتصفح، والمنصة، وسلوك الكاش، وتأثير الصورة في بيئتك. ولا تزال تدوير البروكسي، والجلسات، والاستمرارية، والتعافي بعد التعطل، والتزامن المستمر تحتاج إلى اختبارات خاصة بها قبل ما تسمح لهذي العينة إنها تؤثر في قرار على مستوى الإنتاج.

الإيجابيات والسلبيات

الإيجابيات:

• زاحفات HTTP والمتصفح تشترك في مفاهيم دورة الحياة مع الحفاظ على سياقات استخراج خاصة بكل محرك.
• استخراج HTTP بدقة 1.0 على الكتالوجات الثابتة، والمقالات، وواجهات JSON.
• بنية مشتركة عبر المحركين: RequestQueue، وenqueueLinks مع التحكم في العمق، وDataset.
• مسار المتصفح نفّذ سكربتات النسخة المختبرة واستعاد كل العناصر المستهدفة المتوقعة في اختبارَي JavaScript.
• معالجة نظيفة للأخطاء — استجابة HTTP 500 ظهرت من دون انهيار.
• ترخيص Apache-2.0؛ ويجب على المستخدمين النهائيين مراجعة متطلبات الإشعار ونسب الحقوق.

السلبيات:

• في البيئة المختبرة احتاج محرك المتصفح إلى تثبيت Chromium بشكل منفصل؛ ومن دونه لم يعمل PlaywrightCrawler.
• مسار HTTP ما يقدر يظهر العناصر المستهدفة غير الموجودة في HTML الخام؛ ومن دون التحقق من الاكتمال قد يبدو هذا كأنه نتيجة فارغة صحيحة.
• مسار المتصفح يحمل ملف متصفح إضافيًا وكلفة أعلى لكل صفحة في هذا التشغيل؛ والحجم والتوقيت يختلفان حسب النسخة والمنصة.
• التشغيل الافتراضي يترك مجلد storage/ على القرص.
• يعمل فقط مع Node/TypeScript — وما يفيد إذا كانت بيئتك Python.

لمن يناسب، ولمن لا يناسب

يناسب Crawlee فرق Node أو TypeScript اللي تحتاج إلى الزحف عبر HTTP والمتصفح ضمن مفاهيم مشتركة للطابور ودورة الحياة. والمسار العملي هو تجربة زاحف HTTP أولًا، والتحقق من الحقول المطلوبة، ثم تصعيد فشل اكتمال معرّف نوعيًا إلى معالج متصفح بشرط جاهزية خاص بالهدف. لكن كود DOM داخل المعالج يظل خاصًا بالمحرك حتى لو كانت بنية الطابور واكتشاف الروابط مشتركة.

أعد ضبط التوقعات أو ابحث عن بديل إذا كنت تعمل ضمن بيئة Python (Crawlee مخصص لـ Node/TS — وهناك منفذ Python منفصل، لكن هذه الحزمة اختبرت مكتبة Node)، أو إذا كانت أهدافك ثابتة بالكامل وتفضّل أداة HTTP أبسط ومتخصصة، أو إذا كنت تحتاج إلى سلوك مثبت على نطاق واسع — مثل تدوير البروكسي، وأحواض الجلسات، والاستئناف بعد التعطل — وهي أشياء ما تناولها هذا التطبيق العملي. وإذا أردت استخدام PlaywrightCrawler، فثبّت Chromium أولًا وإلا فلن يعمل أبدًا.

البدائل، بما في ذلك موقع Thunderbit

Crawlee برنامج مفتوح المصدر تديره وتستضيفه بنفسك. ما فيه رسوم استخدام لكل استدعاء من مزود خدمة، لكن تكلفة الحوسبة للمتصفح، وعرض النطاق، والبروكسيات، والتخزين، والمراقبة، والهندسة تبقى كلها تكاليف تشغيلية. أنت اللي يقرر الزاحف، وملف المتصفح، وحالة التخزين، ومنطق الجاهزية.

مراجعة ذات صلة: مراجعة scrapy-playwright.

أما خدمة الاستخراج المُدارة فتنقل مسؤولية الجلب وتشكيل المخطط إلى مزود الخدمة. نحن نبني Thunderbit، لكننا ما شغلناه على هذي العينات، لذلك هذا المقال ما يقدم أي مقارنة من ناحية الجودة أو السرعة أو تكافؤ الميزات أو التكلفة. القرار الحقيقي هنا هو: هل تريد من Crawlee تحكمًا داخل العملية نفسها، أو تريد حدود خدمة تُحاسب لكل استدعاء؟

مراجعات قياس ذات صلة: المقارنة الكاملة بين أدوات استخراج البيانات مفتوحة المصدر، وPlaywright مقابل Puppeteer على الصفحات نفسها، ومراجعة Scrapy من دون طلبات متصفح.

جرّب Thunderbit لاستخراج بيانات الويب

الحكم النهائي

Crawlee خيار قوي لفرق Node أو TypeScript اللي تريد تنسيق زحف مشترك بين HTTP وتشغيل المتصفح. المعالجات اللي تم اختبارها ما كانت قابلة للاستبدال مباشرة: فالانتقال إلى Playwright تطلب page، وانتظار selector مستهدف، واستخراجًا من جهة المتصفح. أما السلوك مع البروكسيات، والجلسات، والاستمرارية، والاستئناف، والنطاق الكبير فما زالت أسئلة مفتوحة.

جرّب Thunderbit لاستخراج بيانات الويب Get Started Free

الأسئلة الشائعة

ما الفرق الفعلي بين زاحفي Crawlee؟ CheerioCrawler يجلب HTML عبر HTTP وما ينفذ JavaScript. أما PlaywrightCrawler فيتحكم في Chromium ويقدر ينفذ سكربتات الصفحة ويأخذ لقطات شاشة، مع كلفة محلية أعلى لكل صفحة. يشتركان في مفاهيم دورة الحياة، لكن ما يشتركان في سياق المعالج نفسه: هذا الاختبار استخدم $ في مسار HTTP، واستخدم page مع انتظار selector مستهدف وتقييم داخل المتصفح في مسار Playwright.

لماذا لا يعمل PlaywrightCrawler بعد تثبيت Crawlee؟ في البيئة المختبرة، تثبيت الحزمة ما وفر ملف متصفح تنفيذي. وتثبيت Chromium عبر npx playwright install chromium حل مشكلة الإقلاع. وكان الحجم المرصود حوالي 82 MiB، لكن القياس الأصلي ما حفظ هل هو حجم نقل أو حجم على القرص، لذلك أعد قياسه بحسب منصتك ونسختك.

هل يستطيع CheerioCrawler استخراج صفحات تُعرض عبر JavaScript؟ لا، ما يقدر ينفذ JavaScript الخاص بالصفحة. لكنه يقدر يطلب نقطة نهاية JSON متاحة يستخدمها العميل، كما توضح نسخة الرد المباشر. وعندما ما تكون البيانات المطلوبة متاحة إلا بعد تنفيذ المتصفح، استخدم زاحف متصفح مع شرط جاهزية مرتبط بتلك الحقول.

هل Crawlee دقيق في الاستخراج الثابت العادي؟ في العينات المضبوطة، رجّعت المعالجات 12/12 من منتجات الكتالوج المتوقعة، و3/3 من فقرات المقال، و8/8 من عناصر JSON المباشرة. هذي فحوص اكتمال لعينة، وليست درجة دقة عامة لمواقع غير مختبرة.

هل Crawlee مجاني للاستخدام التجاري؟ هو منشور تحت Apache-2.0. تأكد من الترخيص الحالي في المستودع وراجع متطلبات الإشعار ونسب الحقوق الخاصة بتوزيعك.

قبل الاعتماد في الإنتاج، اختبر الجوانب اللي ما شملتها هذه العينة: التزامن المتكرر على صفحات ممثلة، وسلوك البروكسي والجلسات، واستعادة الطابور الدائم بعد الانقطاع، وتنظيف عمليات المتصفح، وتصدير Dataset عند الفشل. واحفظ نسخة المتصفح اللي تم حلها وطريق التثبيت مع هذه النتائج. صحيح أن صنفي الزاحف يقللان تباين التنسيق، لكنهما ما يلغيَان الحاجة إلى فحوص جاهزية خاصة بالمحرك، وميزانيات موارد، ومعالجة إخفاقات التشغيل.