قبل بضعة أسابيع، أرسل أحد أفراد فريقنا رابطًا إلى نقاش في GitHub، كان فيه مطوّر يحاول إصلاح منطق المحاولة الثالثة في PlaywrightCrawler عند الساعة 11 مساءً يوم الجمعة. وتحتها مباشرةً ردّ شخص آخر: "فقط استخدم Thunderbit لهذا"، فردّ صاحب السؤال: "هذه ليست الفكرة، أنا أحتاج هذا داخل الـ pipeline الخاص بي." وكلاهما كان على حق. هذا تقريبًا يلخّص جدل Thunderbit مقابل Crawlee في تذكرة واحدة على GitHub.
لقد أمضيت سنوات كافية بين أدوات SaaS وأدوات الأتمتة — وتحياتي لأيامي مع Automation Anywhere — لأعرف أن سؤال "أي أداة أفضل؟" غالبًا ليس السؤال الصحيح. السؤال الأهم هو: من الذي يقوم بعملية الجمع فعلًا، وما الذي يحتاجه بعد ذلك؟ لنغص في الموضوع.
السؤال الحقيقي ليس "أي أداة أفضل" — بل "من الذي يقوم بالـ Scraping؟"
هناك شيء يربك الناس كل مرة يبحثون فيها عن "Crawlee vs [أي شيء]": يتوقعون مواجهة مباشرة بين الميزات، كأنهم يقارنون بين ماكينتي قهوة. لكن Crawlee وThunderbit لا يتنافسان على الوظيفة نفسها. فكل واحد منهما صُمم لشخص مختلف تمامًا يقف أمام مشكلة مختلفة تمامًا.
Crawlee هو مكتبة زحف مفتوحة المصدر طوّرها فريق Apify، وهو يفترض أنك مطوّر مرتاح للعمل بـ JavaScript أو TypeScript أو Python. ستقوم بتثبيته، وكتابة معالجات الطلبات، وتحديد المحددات، ثم شحن الكود. أما Thunderbit فيفترض شيئًا مختلفًا تمامًا: أنك تعمل في فريق المبيعات أو التسويق أو العمليات وتحتاج إلى بيانات منظمة من صفحة ويب الآن، ولا تملك أي رغبة في لمس الطرفية.
| العامل | Crawlee | Thunderbit |
|---|---|---|
| الفئة المستهدفة | مطورون يبنون زواحف مخصّصة | مستخدمون غير تقنيين، وفرق العمليات/المبيعات/التسويق |
| متطلبات الإعداد | تثبيت Node.js أو Python وكتابة كود الـ scraper | تثبيت إضافة المتصفح، ثم النقر على One Click Extract |
| هل يتطلب برمجة؟ | نعم (JS/TS أو Python) | لا |
| أفضل استخدام | خطوط إنتاج، منطق مخصّص | استخراج من صفحة بشكل فوري أو متكرر بصيغة منظمة |
أبدأ بهذه النقطة لأن معظم المقالات المقارنة تتجاوز هذا المنعطف تمامًا، بينما هو في الحقيقة ما يحدد الأداة التي ينبغي حتى أن تفكر فيها. إذا كنت مطورًا وتحتاج تحكمًا دقيقًا في المحاولات المتكررة والـ proxies ومجموعات المتصفحات، فلن يرضيك أي قدر من سهولة النقرة الواحدة. وإذا لم تكن مطورًا، فلن تهمك مرونة Crawlee أصلًا — ببساطة لن تستخدمه.
ما هو Thunderbit؟
Thunderbit هو ما أسميه Web Scraper وكيلًا ذكيًا — أي أن طبقة الذكاء الاصطناعي تتولى تفسير ما يوجد في الصفحة وما ينبغي استخراجه، بدلًا من أن تكتب أنت الـ selectors يدويًا. وتتمثل سير العمل الأساسية في Thunderbit Chrome Extension كالتالي: افتح الصفحة التي تريد البيانات منها، ثم اضغط One Click Extract، وسيقوم الوكيل بقراءة الصفحة وتحليلها، واكتشاف الحقول المفيدة، وتجهيز العملية للتشغيل. سيظهر زر Run Now لتبدأ فورًا إذا أردت، لكنه اختياري — وإن لم تفعل شيئًا، يبدأ الاستخراج تلقائيًا.
هذا فعلًا هو الإعداد بالكامل. لا جلسة بناء schema، ولا تعيين حقول يدوي؛ الوكيل يحلل الصفحة ثم يبدأ الاستخراج تلقائيًا.
وبالإضافة إلى إضافة المتصفح، يوفر Thunderbit أيضًا Web App، وOpen API للوصول البرمجي، ومخدم MCP لاستخدامه كأداة ضمن وكلاء الذكاء الاصطناعي، وCLI لأساليب العمل عبر الطرفية. وهذه النقطة الأخيرة أهم مما يتوقعه الناس — سأعود إليها لاحقًا، لأنها ما يمنع هذا المقال من أن يكون مجرد "اللا-كود ينتصر".
وفي الصفحات المتوافقة، يستطيع Thunderbit أيضًا التعامل مع التصفح عبر الصفحات المتعددة وإثراء الصفحات الفرعية، وبعد الحصول على البيانات يمكنك تصديرها إلى الجداول أو إلى وجهات أخرى مدعومة. وأحب أن أضع هنا التحفّظ نفسه الذي أضعه دائمًا على عبارة "الذكاء الاصطناعي يقرأ الصفحة": نعم، يعمل جيدًا على الصفحات المتوافقة والمصرّح بها، لكنه ليس وعدًا بأن كل إطار عمل JavaScript أو كل جدار مضاد للبوت على الإنترنت سينصاع لك.
ما هو Crawlee؟
Crawlee هو مكتبة مفتوحة المصدر — وليست منتجًا مستضافًا — لبناء الزواحف وعمليات الـ scraping باستخدام JavaScript/TypeScript أو Python. وهو من تطوير Apify، وأريد هنا أن أكون دقيقًا لأن كثيرًا من الناس يخلطون بين الاثنين: Crawlee هو المكتبة، أما Apify فهو المنصة السحابية المنفصلة — وإن كانت مرتبطة — التي يمكنها استضافة وتشغيل المشاريع المبنية على Crawlee. إنهما أشبه بأقارب، لا شيء واحد.
ما تحصل عليه فعليًا مع Crawlee هو صندوق أدوات. فهو يقدّم crawlers قائمة على HTTP للاستخراج الخفيف من المواقع التي لا تعتمد كثيرًا على JavaScript، بالإضافة إلى browser crawlers مبنية على Playwright وPuppeteer للمواقع التي تحتاج إلى rendering حقيقي. كما يدير صفوف الطلبات حتى لا تضطر لتتبع الروابط التي زرتها يدويًا. ويتولى تخزين البيانات المستخرجة. ويدعم autoscaling وsession pools بشكل مدمج، حتى لا تعيد اختراع منطق التوازي من الصفر إذا كنت تزحف عبر آلاف الصفحات.
لكن كل هذا لا يحدث بنقرة زر. أنت تكتب الكود — تحدد request handlers، وتضبط crawler instance، وتخبره بما يجب أن يفعله عند وصوله إلى صفحة. Crawlee يمنحك الهيكل؛ أما البيت فتبنيه أنت.
الفرق الجوهري: منتج استخراج مُدار مقابل مكتبة كود
الوقت حتى أول جدول منظم
هذه هي النقطة التي يظهر فيها الفارق بأوضح صورة. مع Thunderbit، من فتح الصفحة إلى الحصول على جدول بيانات صالح للاستخدام، فأنت تتحدث عن ثوانٍ إلى بضع دقائق على صفحة متوافقة — نقرة واحدة، واترك الوكيل يكتشف ثم يشغّل، وانتهى الأمر.
أما مع Crawlee، فحتى أول crawler بسيط سيستهلك وقت إعداد حقيقي. ستحتاج إلى تثبيت Node.js أو Python، وإضافة حزمة Crawlee، وكتابة request handler، وتحديد selectors يدويًا عبر فحص الصفحة، ثم تشغيله وتصحيح ما تعطّل. وبالنسبة لشخص يجربه لأول مرة، أقدّر أن الأمر قد يستغرق من 30 إلى 60 دقيقة فقط للحصول على أول عملية استخراج ناجحة — وهذا بافتراض أنك تعرف بعض JavaScript أو Python أصلًا.
مستوى التحكم في منطق المتصفح/الزاحف
وهنا يفوز Crawlee بلا نقاش. أنت تتحكم في كل شيء: أي محرك متصفح يُستخدم، وكيف تُدار الجلسات، وكيف تتناوب الـ proxies، وماذا يحدث عند فشل الطلب، وعمق اكتشاف الروابط، وكيف تضبط التوازي. إذا كانت عملية الزحف تحتاج إلى منطق مخصص — مثل تسجيل دخول متعدد الخطوات، أو موقع بتصفح صفحات غريب يكسر الأنماط المعتادة — فإن Crawlee يمنحك اللبنات التي تبني بها ما تريد بالضبط.
أما نهج Thunderbit الوكيل الذكي فيقايض هذه الدقة بالسرعة وسهولة الوصول. أنت لا تكتب المنطق؛ بل يقوم الذكاء الاصطناعي باستنتاجه مما يراه في الصفحة. وهذا ممتاز عندما ينجح، وأقل فائدة عندما تحتاج إلى فرض نمط استخراج محدد جدًا وغير بديهي.
النشر ومن يملك الصيانة
مع Crawlee، أنت من يتحمل مسؤولية النشر. وهذا يعني أنك مسؤول عن الاستضافة (خوادمك الخاصة، أو منصة Apify، أو أي مكان آخر تختاره)، وعن التعامل مع تغييرات بنية الموقع التي قد تكسر الـ selectors، وعن تحديث الاعتمادات البرمجية. إنه عمل مستمر حقيقي، لكنه أيضًا تحكم مستمر حقيقي.
أما Thunderbit فيعمل على بنية مُدارة — إضافة المتصفح تُنفَّذ محليًا داخل جلستك أو في السحابة للمهام المجدولة، وتحديث منطق الاستخراج يحدث من جهة Thunderbit، لا من جهتك.
سيناريوهات عملية
استخراج صفحة لمرة واحدة
تخيل أنك تحتاج إلى نقل صفحة منتجات منافس إلى جدول بيانات قبل اجتماع الساعة الثانية ظهرًا. Thunderbit صُمم بالضبط لهذا النوع من المهام — افتح الصفحة، اضغط One Click Extract، ثم صدّر البيانات. أما Crawlee، ففي مهمة لمرة واحدة فعلًا، فهو مبالغة؛ ستقضي وقتًا في كتابة سكربت أكثر مما ستكسبه من توفير الوقت.
زحف مخصص باستخدام Playwright/Puppeteer
الآن تخيل أنك تبني خط مراقبة يحتاج إلى تسجيل الدخول إلى لوحة تحكم محمية، والتنقل على عمق ثلاث طبقات، واستخراج بيانات من موقع يعرض كل شيء عبر إطار عمل JavaScript مع توقيت DOM غير معتاد. هنا يدخل Crawlee في ملعبه الطبيعي. يمنحك PlaywrightCrawler أدوات أتمتة المتصفح اللازمة للتعامل مع هذا النوع من منطق التنقل المخصص.
زحف ضخم مع طوابير إعادة المحاولة والتخزين
إذا كنت تزحف عبر عشرات الآلاف من الروابط وتحتاج إلى منطق إعادة محاولة تلقائي، واستمرارية في request queue، ومخرجات تخزين منظمة، فإن request queue وdataset abstractions المدمجة في Crawlee صُممت تحديدًا لهذا الحجم. هذا ليس استخدام Thunderbit عبر إضافة المتصفح — فهو أداة لصفحة واحدة في كل مرة (أو صفحات فرعية متوافقة)، وليس نظامًا لإدارة الطوابير.
استدعاء الاستخراج من وكيل ذكاء اصطناعي
هذا هو السيناريو الذي يخطئ فيه الناس غالبًا عند عقد المقارنات. فالمطورون الذين يبنون سير عمل لوكلاء الذكاء الاصطناعي يفترضون أحيانًا أن "الوكيل يحتاج بيانات" تعني تلقائيًا "اكتب كود Crawlee مخصصًا ولفّه كأداة." وهذا مسار صحيح. لكن مخدم MCP الخاص بـ Thunderbit موجود تحديدًا لكي يتمكن مضيف ذكاء اصطناعي — مثل Claude أو Cursor أو أي عميل متوافق مشابه — من استدعاء قدرة Thunderbit على الاستخراج كأداة، من دون أن يكتب أحد crawler مخصصًا. هذه واجهة مختلفة فعلًا عن سير العمل بالنقرة الواحدة في المتصفح، وتتطلب إعدادًا، وليست "انقر وانتهى". لكنها أيضًا ليست بنفس الجهد الذي يتطلبه بناء أداة مبنية على Crawlee من الصفر.
المواقع الديناميكية، والنطاق، والاعتمادية
أريد أن أكون حذرًا هنا لأن هذه هي النقطة التي تميل فيها اللغة التسويقية — بما فيها لغتي أحيانًا تاريخيًا — إلى المبالغة. يمكن لـ browser crawlers في Crawlee تنفيذ JavaScript، وانتظار المحتوى الديناميكي، والتفاعل مع الصفحات كما يفعل المستخدم الحقيقي — وهذا مفيد جدًا للمواقع الثقيلة في rendering. وبالمثل، تعمل إضافة Thunderbit داخل متصفح حقيقي ويمكنها التعامل مع الصفحات المعروضة عبر JavaScript التي تفتحها.
لكن لا أحد منهما يضمن النجاح في كل مكان. يمنح Crawlee المطورين الأدوات اللازمة لضبط تناوب الـ proxies ومجموعات الجلسات بأنفسهم — أي تحكم يدوي قابل للضبط، لا تجاوزًا تلقائيًا. أما Thunderbit فيطبّق rendering مُدارًا ومعالجة مضادّة للبوت على الصفحات المصرح بها والمدعومة، وهذا أيضًا ليس ادعاءً بأنه "يعمل على كل شيء". إذا قرأت أي مقارنة تعدك بنجاح 100% ضد كل أنظمة الحماية من البوتات على الإنترنت، فاعلم أنها كاذبة صراحةً، بلا تلطيف.
التسعير والترخيص والتكلفة الإجمالية
Crawlee نفسه مجاني ومفتوح المصدر — فنسخة Python مثلًا تأتي تحت رخصة Apache 2.0. لكن "مجاني" لا يعني "بلا تكلفة". فأنت تدفع من وقت المطورين لكتابة الزواحف وصيانتها، ومن تكاليف الاستضافة (خوادمك أو منصة Apify، وهي منتج مدفوع منفصل عن المكتبة نفسها)، ومن رسوم خدمات الـ proxy إذا كانت المواقع المستهدفة تحتاج إلى تدوير عناوين IP لتجنب الحظر.
أما Thunderbit فيعمل بنموذج اشتراك/خطة مع استخدام قائم على الاعتمادات — وأحيلك مباشرةً إلى صفحة Thunderbit Pricing لأن هذه الأرقام تتغير، ولن أذكر رقمًا قد يصبح قديمًا قبل أن تقرأ هذا.
مقارنة الصيانة بصراحة: زواحف Crawlee تتعطل عندما يغيّر الموقع المستهدف بنيته، لأن selectors الخاصة بك كُتبت ضد هيكل DOM محدد. وعندها يجب أن يلاحظ أحدهم العطل ويصلح الكود. أما الاستخراج الوكيل في Thunderbit فيعيد تحليل الصفحة في كل تشغيل، ما يقلل — لا يلغي — هذا النوع من الأعطال؛ فالتغييرات الكبيرة في تصميم الموقع المستهدف قد تربك العملية أيضًا، لكنك لا تدير selectors ثابتة مكتوبة يدويًا بالطريقة نفسها.
من ينبغي أن يختار Thunderbit؟
إذا لم تكن مطورًا وتحتاج إلى بيانات منظمة من صفحات الويب — لقوائم العملاء المحتملين، أو تسعير المنافسين، أو أبحاث السوق، أو غير ذلك — فإن Thunderbit صُمم تمامًا لحالتك. وينطبق الشيء نفسه إذا كنت مطورًا تريد تسليم أداة استخراج ذاتية الخدمة لفريق غير تقني، أو إذا كنت تريد وصولًا برمجيًا عبر Open API من دون بناء crawler كامل من الصفر.
من ينبغي أن يختار Crawlee؟
إذا كنت تبني خط بيانات إنتاجي يحتاج إلى منطق تنقّل مخصص، وتحكم دقيق في المحاولات والـ proxies، وتريد امتلاك الكود المصدري من البداية إلى النهاية، فإن Crawlee هو الأساس المناسب. وهو أيضًا الخيار الأفضل إذا كان الزحف يجب أن يعمل على نطاق حقيقي — عشرات الآلاف من الصفحات مع إدارة request queue — وهو أصلًا ليس نوع المشكلة الذي صُممت له تجربة إضافة المتصفح.
هل يمكن للفرق استخدام الاثنين معًا؟
عمليًا، نعم، ولا أرى هذا جوابًا مراوغًا. لقد رأيت هذا النمط يتكرر في كثير من الشركات التي عملت معها: فريق الهندسة يدير خطًا مبنيًا على Crawlee للمهام المتكررة واسعة النطاق والمنظمة التي تغذي مستودع البيانات، بينما تستخدم فرق المبيعات أو التسويق أو العمليات إضافة Thunderbit للمتصفح أو Web App في مهام "أحتاج بيانات هذه الصفحة الآن" التي كان من الممكن أن تتحول إلى تذكرة في قائمة مهام الهندسة. لا يوجد تكامل رسمي يربط الاثنين معًا — ولن أخترع واحدًا — لكن من الناحية المعمارية، يحل كل منهما مشكلة قريبة بما يكفي بحيث ينتهي الأمر بكثير من الفرق إلى تشغيل الاثنين معًا.
الخلاصة
إذا كنت مطورًا تبني شيئًا يجب أن يعيش داخل codebase، أو يتوسع إلى آلاف الصفحات، أو يتعامل مع منطق تنقل مخصص فعلًا، فإن Crawlee يمنحك مستوى التحكم الذي تحتاجه — مقابل وقتك والصيانة المستمرة. أما إذا كنت أي شخص آخر يحتاج إلى استخراج بيانات من صفحة ويب من دون كتابة كود، أو مطورًا يريد إتاحة الاستخراج كأداة لوكيل ذكاء اصطناعي من دون بناء crawler من الصفر، فإن Thunderbit هو الطريق الأسرع. لا يوجد أداة "أفضل" بشكل مطلق. كل أداة تحل مشكلة مختلفة لأشخاص مختلفين، وأكبر خطأ هنا هو اختيار الأداة الخطأ لحالتك.
الأسئلة الشائعة
هل Crawlee هو نفسه Apify؟ لا. Crawlee هو مكتبة الزحف مفتوحة المصدر التي يطوّرها فريق Apify. أما Apify فهي منصة سحابية منفصلة يمكنها استضافة وتشغيل المشاريع المبنية على Crawlee، بالإضافة إلى خدمات أخرى مثل الـ proxies والجدولة. هما مرتبطان لكنهما منتجان مختلفان وبنماذج تسعير مختلفة.
هل Crawlee مجاني؟ المكتبة نفسها مجانية ومفتوحة المصدر (ونسخة Python تستخدم رخصة Apache 2.0). أما التكاليف الحقيقية فتأتي من وقت المطورين، وبنية الاستضافة، وأي خدمات proxy قد تحتاجها — وليس من رسوم الترخيص.
هل يدعم Thunderbit الوصول عبر API وMCP للمطورين؟ نعم. فإلى جانب إضافة المتصفح، يقدّم Thunderbit Open API للوصول البرمجي، ومخدم MCP الذي يسمح لمضيفات الذكاء الاصطناعي المتوافقة باستدعاء أدوات الاستخراج الخاصة بـ Thunderbit مباشرةً.
ما الأسهل لشخص لا يملك خلفية برمجية؟ Thunderbit، بلا شك. فمسار One Click Extract في إضافة المتصفح لا يتطلب كودًا، ولا كتابة selectors، ولا إعداد schema. أما Crawlee فيفترض منذ البداية إلمامًا بـ JavaScript/TypeScript أو Python.
أي أداة تمنح تحكمًا أكبر في سلوك الزاحف مثل إعادة المحاولة والـ proxies؟ Crawlee، وبفارق كبير. فهو يوفّر session pools، وتناوب الـ proxies، وإدارة request queue، ومنطق إعادة المحاولة كعناصر قابلة للضبط للمطورين. أما Thunderbit فيدير هذه الجوانب من جانبه، مقايضًا هذا التحكم اليدوي بالبساطة والسرعة.
