Οι περισσότεροι γνωρίζουν το Crawlee όταν προσπαθούν να απαντήσουν σε μια διαφορετική ερώτηση: «ποιο headless browser να χρησιμοποιήσω;» Αυτή είναι η λάθος ερώτηση — και ο λόγος είναι ακριβώς το Crawlee. Δεν είναι browser. Είναι το Node/TypeScript framework που τον αξιοποιεί όταν τον χρειάζεσαι και τον παρακάμπτει όταν δεν τον χρειάζεσαι.
Πέρασα μερικές ημέρες δοκιμάζοντας το Crawlee 3.17.0 πάνω σε ένα ελεγχόμενο σύνολο από fixtures και σε μερικά δημόσια demo sites, σε Node v22.22.3 και macOS. Η βασική υπόσχεση — μία βιβλιοθήκη, ένα API, με από κάτω είτε HTTP crawler είτε πραγματικό browser — ήταν αυτό που ήθελα περισσότερο να τεστάρω, γιατί αυτή είναι η υπόσχεση που κρίνει αν το Crawlee αξίζει να μπει στο stack σου ή αν αρκεί να πας κατευθείαν στο Playwright. Σύντομη εκδοχή: η ιστορία των δύο μηχανών στέκει, με μερικές επιφυλάξεις που θα αναφέρω στη συνέχεια.
Τι είναι πραγματικά το Crawlee — και τι δεν είναι
Το Crawlee περιγράφεται ως βιβλιοθήκη web scraping και αυτοματισμού browser για Node.js, φτιαγμένη για αξιόπιστους crawlers. Η επίσημη τοποθέτηση είναι ευρεία: εξαγωγή δεδομένων για AI, LLMs, RAG ή GPTs· λήψη HTML, PDF, JPG, PNG και άλλων αρχείων· συμβατότητα με Puppeteer, Playwright, Cheerio, JSDOM και raw HTTP· με ή χωρίς ορατό browser· με proxy rotation ενσωματωμένο. Είναι πολλά όλα αυτά, οπότε βοηθά να ξεκαθαρίσουμε τι δεν είναι το Crawlee.
Δεν είναι rendering engine. Δεν έχει δικό του browser. Όταν θέλεις να εκτελεστεί JavaScript, το Crawlee χειρίζεται το Playwright ή το Puppeteer, τα οποία με τη σειρά τους χειρίζονται το Chromium (ή άλλον browser). Επίσης δεν είναι hosted υπηρεσία που καλείς μέσω δικτύου — είναι dependency που εγκαθιστάς και τρέχεις εσύ. Αυτό που είναι το Crawlee, με ακρίβεια, είναι το layer πάνω από τον fetcher: οι crawler κλάσεις, το request queue, το storage, η λογική παρακολούθησης συνδέσμων. Σκέψου το σαν το crawl framework, με μια εναλλάξιμη μηχανή από κάτω.
Για την ιστορία, η έκδοση που δοκίμασα ήταν η 3.17.0 (κυκλοφόρησε στις 2026-06-04), είναι σε TypeScript, με άδεια Apache-2.0, και το repo είχε περίπου 24.6k stars στις 2026-07-09 στο apify/crawlee. Τα αστέρια αλλάζουν — το repo κέρδισε 53 μέσα στις δύο ημέρες που το παρακολουθούσα — οπότε δες αυτόν τον αριθμό ως στιγμιότυπο, όχι ως σταθερό δεδομένο.
Οι δύο μηχανές: CheerioCrawler vs PlaywrightCrawler
Εδώ είναι που ο σχεδιασμός δικαιώνει την ύπαρξή του — και εκεί ακριβώς αφιέρωσα τον περισσότερο χρόνο μου.
Το CheerioCrawler είναι η HTTP διαδρομή. Κατεβάζει το ακατέργαστο HTML μέσω δικτύου και το αναλύει με Cheerio — χωρίς browser, χωρίς εκτέλεση JavaScript, χωρίς rendering. Είναι γρήγορο και οικονομικό. Το PlaywrightCrawler είναι η browser διαδρομή. Ανοίγει πραγματικό Chromium, αποδίδει τη σελίδα μαζί με ό,τι JavaScript χτίζει το DOM και μπορεί ακόμη και να τραβήξει screenshots.
Δύο διαφορετικές μηχανές με πραγματικά διαφορετικές δυνατότητες. Το νόημα που θέλει να περάσει το Crawlee είναι ότι φορούν τα ίδια ρούχα. Και τα δύο δέχονται requestHandler. Και τα δύο εκθέτουν run(). Και τα δύο ακολουθούν links με enqueueLinks. Η μετάβαση από τη μία μηχανή στην άλλη είναι αλλαγή κλάσης, όχι ξαναγράψιμο — το επιβεβαίωσα κρατώντας την extraction λογική byte-identical και αλλάζοντας μόνο το crawler class που την τύλιγε.
Ένα σημείο χρειάζεται ακρίβεια, γιατί εκεί σταματά η ισοδυναμία: το content handle διαφέρει. Μέσα σε handler του CheerioCrawler παίρνεις $ — ένα στατικό, ήδη αναλυμένο DOM που το κάνεις query σαν jQuery. Μέσα σε browser handler παίρνεις ένα live page object. Άρα το queue, το routing, και το plumbing του τύπου «σπρώξε αυτά τα δεδομένα, ακολούθησε αυτά τα links» μένουν ίδια, αλλά το σημείο όπου διαβάζεις πραγματικά τη σελίδα αλλάζει μορφή. Το ίδιο λένε και τα docs του Crawlee — το κοινό interface περιορίζεται στις crawl operations, ενώ η πρόσβαση στο content είναι αυτό που διαφέρει.
| Μηχανή | Πώς κάνει fetch | Εκτελεί JavaScript; | Η δοκιμή μου (1 δυναμική σελίδα) | Ιδανική για |
|---|---|---|---|---|
CheerioCrawler | Raw HTTP + parsing με Cheerio | Όχι | ~0.035s | Static HTML, JSON APIs, ταχύτητα |
PlaywrightCrawler | Πραγματικό Chromium μέσω Playwright | Ναι | ~4.967s | Σελίδες με JS rendering, screenshots |
Αυτοί οι χρόνοι προέρχονται από ένα μόνο μηχάνημα και μία μόνο εκτέλεση — δεν είναι benchmark, είναι απλώς η εικόνα του trade-off. Η διαδρομή με browser κόστισε περίπου δύο τάξεις μεγέθους περισσότερο χρόνο στο ίδιο URL. Αυτό είναι το τίμημα του rendering, και γι’ αυτό δεν το επιλέγεις ως προεπιλογή.
Η δοκιμή: ίδιο URL, 0 vs 8/8
Οι υποσχέσεις κοστίζουν λίγο. Ο λόγος που εμπιστεύομαι την ιστορία των δύο μηχανών είναι ότι μπόρεσα να την κάνω να αποτύχει — και μετά να τη διορθώσω αλλάζοντας μόνο μία κλάση.
Έστησα ένα τοπικό δυναμικό fixture — μια σελίδα καταλόγου όπου οι κάρτες προϊόντων εισάγονται από JavaScript μετά το load, ακριβώς το είδος σελίδας που έχει γίνει πια ο κανόνας στο σύγχρονο web. Έστρεψα το CheerioCrawler προς τα εκεί. Επέστρεψε 0 product cards. Δεν είναι bug· είναι φυσική συνέπεια. Το Cheerio δεν εκτέλεσε ποτέ το JavaScript, άρα οι κάρτες δεν υπήρξαν ποτέ στο HTML που ανέλυσε. Μετά έστρεψα το PlaywrightCrawler στο ακριβώς ίδιο URL, δεν άλλαξα τίποτε άλλο, και απέδωσε 8 από 8 προϊόντα και πήρε screenshot ως απόδειξη.
Για να βεβαιωθώ ότι δεν ήταν ιδιοτροπία του δικού μου fixture, έτρεξα το ίδιο μοτίβο σε ένα δημόσιο site — το Quotes to Scrape JavaScript demo page, που χτίζει τα quotes client-side. Το ίδιο αποτέλεσμα προς την ίδια κατεύθυνση: το CheerioCrawler είδε 0 quotes, το PlaywrightCrawler ανέκτησε 10.
Θέλω να είμαι προσεκτικός με το τι αποδεικνύει αυτό. Είναι καθαρή επιβεβαίωση μιας υπόσχεσης που το Crawlee ήδη τεκμηριώνει — το framework μοιράζεται την ίδια base class και το ίδιο interface ανάμεσα στους τύπους crawler από την έκδοση 3.0. Άρα εδώ μιλάμε για επαλήθευση, όχι για ανακάλυψη. Αλλά αυτό ακριβώς είναι το νόημα: το marketing μήνυμα «ένα interface, HTTP ή browser» είναι αληθινό, και εδώ έχεις το 0 → πλήρη δεδομένα και στο fixture που ελέγχω και σε site που δεν ελέγχω.
Πού κερδίζει η HTTP διαδρομή
Θα ήταν εύκολο να διαβάσει κανείς τα παραπάνω ως «χρησιμοποίησε πάντα browser». Μην το κάνεις. Ολόκληρος ο λόγος που έχει σημασία ο σχεδιασμός δύο μηχανών είναι ότι ο browser είναι το ακριβό fallback, όχι η προεπιλογή.
Σε static περιεχόμενο, το CheerioCrawler ήταν ακριβές και γρήγορο. Το static catalog fixture μου επέστρεψε 12 από 12 προϊόντα με πλήρη ανάκτηση, ακολουθώντας την pagination μέσω enqueueLinks({ selector: '.next-page' }), σε περίπου 0.155 δευτερόλεπτα. Μια άρθρο-σελίδα έδωσε τον τίτλο της και όλες τις 3 από 3 παραγράφους του σώματος, με το boilerplate για login/subscribe/copyright να ξεχωρίζει καθαρά από το περιεχόμενο.
Αυτό που αξίζει να κρατήσεις: μια σελίδα της οποίας τα δεδομένα φορτώνονται με JavaScript συχνά έχει από πίσω της ένα JSON API. Τα δεδομένα του δυναμικού fixture μου ζούσαν σε ένα endpoint, και όταν έστρεψα το CheerioCrawler κατευθείαν σε αυτό το API, ανέκτησε 8 από 8 προϊόντα — χωρίς browser, σε περίπου 0.035 δευτερόλεπτα. Τα ίδια δεδομένα που η browser διαδρομή χρειάστηκε σχεδόν πέντε δευτερόλεπτα για να αποδώσει. Το μάθημα είναι παλιό αλλά εξακολουθεί να ισχύει: αν μπορείς να αναπαράγεις το υποκείμενο request, κάν’ το αντί να ανοίγεις Chromium. Το Crawlee σου επιτρέπει να πάρεις αυτή την απόφαση ανά crawler χωρίς να αλλάξεις framework.
Το κομμάτι του crawl framework (ο λόγος να προτιμήσεις το Crawlee αντί για ένα απλό browser lib)
Αν το μόνο που χρειαζόσουν ήταν να αποδώσεις μία σελίδα, δεν θα χρειαζόσουν το Crawlee — θα χρησιμοποιούσες απευθείας Playwright ή Puppeteer. Αυτό που δεν σου δίνει μια απλή browser βιβλιοθήκη είναι το crawl: queue, deduplication, έλεγχος βάθους, retries. Αυτό είναι το μέρος του Crawlee που δεν έχει σχέση με τις μηχανές καθαυτές.
Έτρεξα crawl στο ίδιο hostname από το root του fixture με enqueueLinks και παρακολούθηση βάθους. Το Crawlee διέσχισε 11 σελίδες με βάθη {0:1, 1:3, 2:7} — μία root, τρεις σελίδες ένα βήμα πιο έξω, επτά σελίδες δύο βήματα πιο έξω — και σεβάστηκε το maxRequestsPerCrawl ως συνθήκη τερματισμού. Το RequestQueue διαχειρίστηκε τη λογιστική. Όταν έστρεψα ένα request σε σελίδα που επέστρεφε HTTP 500, το Crawlee έκανε retry και μετά έδωσε την αποτυχία μέσω του failedRequestHandler αντί να την καταπιεί σιωπηλά ή να ρίξει το run.
Αυτό είναι το πιο ισχυρό επιχείρημα υπέρ του Crawlee σε σχέση με ένα αυτόνομο browser tool: η ενορχήστρωση του crawl είναι ενσωματωμένη και, το σημαντικότερο, είναι η ίδια είτε η μηχανή από κάτω είναι HTTP είτε browser. Γράφεις μία φορά τη λογική queue-and-follow. Και αποφασίζεις ξεχωριστά αν κάθε crawler θα κάνει render JavaScript.
Εγκατάσταση και το κρυφό browser download
Η εγκατάσταση ήταν κυρίως απροβλημάτιστη, με μία παγίδα που θα πιάσει τους νέους χρήστες.
Το npm install crawlee playwright ολοκληρώθηκε καθαρά — χωρίς vulnerabilities. Όμως το PlaywrightCrawler δεν θα ανοίξει αν δεν τρέξεις επίσης npx playwright install chromium, που κατεβάζει ένα Chromium binary περίπου 81.7 MiB. Η εγκατάσταση του πακέτου crawlee από μόνη της δεν φέρνει browser. Αν παραλείψεις αυτό το βήμα και πας κατευθείαν σε browser crawler, θα συναντήσεις error εκκίνησης που δεν είναι καθόλου προφανές αν δεν γνωρίζεις ήδη το packaging model του Playwright. Είναι inherited συμπεριφορά του Playwright, όχι πρόβλημα του Crawlee, αλλά είναι πραγματικό friction στο πρώτο run και αξίζει να το ξέρεις.
Μια ακόμη λειτουργική σημείωση: από προεπιλογή το Crawlee γράφει σε τοπικό φάκελο storage/. Το δικό μου test harness το ανακατεύθυνε σε προσωρινό scratch dir και απενεργοποίησε τη διατήρηση δεδομένων για να μείνει καθαρό το περιβάλλον, αλλά μια απλή εκτέλεση θα αφήσει φάκελο storage/ στο project σου. Δεν είναι πρόβλημα — απλώς κάτι που καλό είναι να ξέρεις πριν εμφανιστεί στο git status σου.
Ένας τρίτος κινητήρας, σύντομα
Η ιστορία ισοδυναμίας του Crawlee δεν περιορίζεται στα Cheerio και Playwright. Υπάρχει επίσης το PuppeteerCrawler, και έλεγξα πόσο μακριά φτάνει η υπόσχεση «ίδιο interface» και προς αυτό — σε επίπεδο κλάσης και API surface, όχι με live crawl.
Και οι τρεις crawler κλάσεις καταλήγουν στην ίδια βάση BasicCrawler. Το CheerioCrawler περνά από ένα HttpCrawler· τα PlaywrightCrawler και PuppeteerCrawler περνούν και τα δύο από ένα κοινό BrowserCrawler. Εξετάζοντας το εγκατεστημένο package, 24 public methods είναι κοινά και στις τρεις μηχανές, συμπεριλαμβανομένων των queue και storage operations πάνω στα οποία χτίζεται όλος ο σχεδιασμός — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. Το PuppeteerCrawler και το PlaywrightCrawler μάλιστα εκθέτουν ακριβώς το ίδιο public method set. Οι διαφορές ανάμεσα στις μηχανές εμφανίζονται μόνο στο σημείο HTTP-versus-browser — δηλαδή ακριβώς εκεί όπου θα περίμενε κανείς.
Το όριο που αξίζει να ειπωθεί καθαρά: δεν έτρεξα live PuppeteerCrawler crawl. Το puppeteer peer dependency είναι προαιρετικό και δεν είχε εγκατασταθεί στο test pack μου, και η δοκιμή του θα σήμαινε ακόμη ένα browser download. Άρα εδώ η ισοδυναμία του Puppeteer επιβεβαιώνεται δομικά — ίδια base class, ίδια κοινά methods, ίδια μορφή handler context — όχι με εκτελεσμένο run. Και ακόμη κι όταν το interface ταιριάζει, η συμπεριφορά από κάτω δεν είναι απόλυτα ίδια: η επίσημη καθοδήγηση του Crawlee σημειώνει ότι το Playwright κάνει auto-wait για τα στοιχεία, ενώ το Puppeteer σε βάζει να περιμένεις ρητά. Αυτό είναι χαρακτηριστικό της μηχανής, όχι ελάττωμα του Crawlee, αλλά σημαίνει ότι το «ίδιο API» δεν σημαίνει «ίδιος κώδικας μέσα σε κάθε handler».
Τι δεν δοκίμασα
Να τι άφησα επίτηδες εκτός αυτής της φάσης, ώστε να μη διαβάσεις τα αποτελέσματά μου ευρύτερα απ’ όσο επιτρέπουν.
- Κλίμακα. Όλα έτρεξαν σε μικρά fixtures και σύντομα δημόσια crawls. Δεν υπήρξε run 100–1.000 σελίδων, άρα δεν μπορώ να μιλήσω για autoscaling ή σταθερότητα υπό πραγματικό φορτίο.
- Persistence και resume του queue. Δεν σταμάτησα ποτέ ένα crawl στη μέση για να δω αν το
RequestQueueσυνεχίζει καθαρά μετά από crash. Αυτό είναι βασική δυνατότητα για μεγάλα jobs και εδώ δεν ελέγχθηκε. - Dataset και KeyValueStore export. Έγραψα χειροκίνητα τα JSON/CSV exports στο harness. Τις ενσωματωμένες δυνατότητες export του
Dataset/KeyValueStore— ίσως το πιο «άνετο» κέρδος από τη χρήση του framework — δεν τις δοκίμασα. - Proxy και session pools. Το Crawlee φέρνει proxy rotation και fingerprinting. Τα αντιμετωπίζω αυστηρά ως θέμα συμμόρφωσης και λειτουργίας, όχι ως selling point για παράκαμψη anti-bot, και δεν τα στρίμωξα ούτε προς τη μία ούτε προς την άλλη κατεύθυνση.
Και οι χρόνοι παντού είναι από ένα μηχάνημα και μία εκτέλεση. Δείχνουν τη μορφή του κόστους HTTP-versus-browser. Δεν είναι benchmark, και δεν θα τους παρέθετα ως τέτοιους.
Πλεονεκτήματα και μειονεκτήματα
Πλεονεκτήματα
- Ένα API surface τόσο για HTTP όσο και για browser crawling — η αλλαγή μηχανής είναι όντως αλλαγή κλάσης, επιβεβαιωμένη με 0 → πλήρη δεδομένα τόσο σε τοπικό fixture όσο και σε δημόσιο site.
- Πραγματικό crawl framework:
RequestQueue,enqueueLinksμε έλεγχο βάθους, retries καιfailedRequestHandler, όχι απλώς page renderer. - Ακριβής HTTP extraction (12/12 static, 3/3 paragraphs άρθρου, 8/8 μέσω JSON API) όταν το JavaScript δεν παρεμβάλλεται.
- Η browser διαδρομή ανακτά περιεχόμενο που η HTTP διαδρομή φυσικά δεν μπορεί να δει, και τραβά screenshots.
- Apache-2.0, TypeScript, με ενεργή συντήρηση.
Μειονεκτήματα
- Οι browser crawlers χρειάζονται ξεχωριστό
npx playwright install chromium(~81.7 MiB) που τοnpm install crawleeδεν καλύπτει — εύκολο να το ξεχάσεις. - Το browser rendering έχει πραγματικό κόστος ανά σελίδα (~5s έναντι υποδευτερολέπτου στο δικό μου one-page test).
- Η προεπιλεγμένη δημιουργία φακέλου
storage/στις απλές εκτελέσεις. - Κλίμακα, persistence/resume του queue και η ευκολία export του Dataset δεν αποδείχθηκαν στις δοκιμές μου.
- Τα proxy και fingerprinting features πρέπει να χρησιμοποιούνται εντός των όρων ενός site και του νόμου — ευθύνη, όχι feature για να στηριχτείς τυφλά.
Πότε να διαλέξεις Crawlee και πότε managed API
Το Crawlee είναι εργαλείο «χτίζω μόνος μου», και αυτό είναι η σωστή επιλογή για πολλές ομάδες. Διάλεξέ το όταν θέλεις να έχεις τον crawler μέσα στο δικό σου Node codebase, να συνδυάζεις HTTP και browser crawling στο ίδιο project χωρίς να αλλάζεις framework, και να ελέγχεις εσύ το queue και το storage. Αν είσαι άνετος με το να τρέχεις — και τελικά να κλιμακώνεις — ένα browser fleet, το Crawlee σου δίνει μια καθαρή, καλοσχεδιασμένη ραχοκοκαλιά για να στηριχτείς.
Η άλλη διαδρομή είναι να μην τρέχεις καθόλου τέτοια υποδομή. Αν δεν θέλεις να ασχολείσαι με Chromium instances, proxy rotation και anti-bot handling, η εναλλακτική είναι ένα managed API — και εκεί ταιριάζει το δικό μας developer stack στο Thunderbit. Για τεχνικούς χρήστες, το Thunderbit δεν είναι το Chrome extension· είναι ένα AI scraping API, MCP server και CLI. Καλείς POST /distill για να μετατρέψεις μια σελίδα σε καθαρό, LLM-ready Markdown ή POST /extract με JSON Schema για να πάρεις δομημένα δεδομένα πίσω, με renderMode σε none, basic ή full ώστε να αποφασίζεις εσύ πότε αξίζει το πλήρες browser render. Ο MCP server επιτρέπει σε έναν AI agent (Claude, Cursor και άλλους MCP clients) να κάνει scrape μέσα στη ροή της εργασίας, και το CLI τρέχει από terminal ή CI:
Δοκιμάστε το Thunderbit για εξαγωγή δεδομένων από το web
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Η διαφορά που μετρά για τους developers: το Crawlee σου δίνει τις πρώτες ύλες — rendered HTML, parsed nodes — και εσύ αναλαμβάνεις όλο το pipeline· ένα managed API σου επιστρέφει δομημένο JSON που ταιριάζει σε schema, με JS rendering, CAPTCHAs και anti-bot διαχείριση από την πλευρά του server. Άλλες δουλειές. Αν θέλεις μέγιστο έλεγχο και δεν σε πειράζουν οι ops, Crawlee. Αν θέλεις τα δεδομένα χωρίς να τρέχεις browser fleet, η managed λύση. Πολλές ομάδες καταλήγουν να χρησιμοποιούν και τα δύο: το ένα για custom crawls και το άλλο για τις περιπτώσεις «δώσε μου απλώς τα δομημένα δεδομένα». Μπορείς να δεις το κόστος και στο τιμολόγιο του Thunderbit.
Συμπέρασμα
Αξίζει να χρησιμοποιήσεις το Crawlee; Ναι — αν είσαι developer σε Node ή TypeScript και θέλεις ένα ενιαίο framework που καλύπτει HTTP και browser crawling με πραγματικό crawl queue από κάτω. Η υπόσχεση των δύο μηχανών είναι ο λόγος να το επιλέξεις, και αυτή η υπόσχεση άντεξε καθαρά στα fixtures μου: το ίδιο URL πέρασε από το 0 στα πλήρη δεδομένα με αλλαγή μίας κλάσης, η static extraction ήταν ακριβής και γρήγορη, και το queue-and-depth crawling λειτούργησε όπως περιγράφεται.
Μπες με δύο πράγματα στο μυαλό σου. Προϋπολόγισε το κρυφό browser download την πρώτη φορά που θα χρησιμοποιήσεις το PlaywrightCrawler, και μην υποθέτεις ότι τα μέρη που δεν δοκίμασα — κλίμακα, crash-resume, ενσωματωμένα exports — συμπεριφέρονται εξίσου καλά με αυτά που δοκίμασα, πριν τα τρέξεις στο δικό σου workload. Ως βάση για να χτίσεις τον δικό σου crawler, το Crawlee είναι ένα ισχυρό, καλοσχεδιασμένο κομμάτι engineering. Ως ολοκληρωμένο, hands-off data pipeline, είναι αφετηρία — όχι ο τελικός προορισμός.
Δοκιμάστε το Thunderbit για εξαγωγή δεδομένων από το web Get Started Free
Συχνές ερωτήσεις
Είναι το Crawlee δωρεάν και υπό ποια άδεια κυκλοφορεί;
Ναι. Το Crawlee είναι open source υπό άδεια Apache-2.0 και εγκαθίσταται από το npm (npm install crawlee). Η έκδοση που δοκίμασα ήταν η 3.17.0. Η χρήση των browser crawlers απαιτεί ξεχωριστό Chromium download μέσω Playwright, το οποίο επίσης είναι δωρεάν αλλά προσθέτει περίπου 81.7 MiB στο setup σου.
CheerioCrawler vs PlaywrightCrawler — ποιο να χρησιμοποιήσω;
Χρησιμοποίησε το CheerioCrawler όταν τα δεδομένα βρίσκονται στο raw HTML ή σε ένα υποκείμενο JSON API — είναι πολύ πιο γρήγορο και δεν ανοίγει ποτέ browser. Χρησιμοποίησε το PlaywrightCrawler όταν το περιεχόμενο αποδίδεται από JavaScript, κάτι που φαίνεται όταν η HTTP διαδρομή επιστρέφει άδεια αποτελέσματα. Στις δοκιμές μου η HTTP μηχανή επέστρεψε 0 items σε σελίδα με JS rendering και η browser μηχανή επέστρεψε τα πάντα. Επειδή μοιράζονται το ίδιο API, η μετάβαση είναι αλλαγή κλάσης, όχι ξαναγράψιμο.
Χρειάζεται το Crawlee browser για να τρέξει;
Μόνο για τους browser crawlers. Το CheerioCrawler δεν χρειάζεται browser καθόλου. Το PlaywrightCrawler (και το PuppeteerCrawler) χρειάζονται browser binary — εγκατέστησέ το με npx playwright install chromium. Σημείωσε ότι το npm install crawlee μόνο του δεν κατεβάζει browser, και αυτό είναι το πιο συχνό πρώτο gotcha.
Μπορεί το Crawlee να χειριστεί pagination και multi-page crawls;
Ναι, και αυτός είναι βασικός λόγος να το προτιμήσεις από μια απλή browser βιβλιοθήκη. Το enqueueLinks ακολουθεί links (συμπεριλαμβανομένων pagination selectors όπως .next-page), το RequestQueue κάνει deduplication και διαχειρίζεται το crawl, και έχεις έλεγχο βάθους μαζί με όρια maxRequestsPerCrawl. Στη δοκιμή, ένα crawl στο ίδιο hostname πέρασε από 11 σελίδες σε βάθη 0–2, και τα αποτυχημένα requests εμφανίστηκαν μέσω failedRequestHandler.
Πώς συγκρίνεται το Crawlee με ένα hosted scraping API;
Το Crawlee είναι self-hosted: γράφεις και τρέχεις εσύ τον crawler, και αναλαμβάνεις scaling, proxies και anti-bot handling. Ένα managed API όπως τα endpoints distill/extract του Thunderbit επιστρέφει καθαρό Markdown ή δομημένο JSON που ταιριάζει σε schema, με rendering και anti-bot διαχείριση από την πλευρά του server, προσφερόμενα μέσω API, MCP server και CLI. Διάλεξε Crawlee για μέγιστο έλεγχο στο δικό σου pipeline· διάλεξε managed API όταν δεν θέλεις να τρέχεις και να κλιμακώνεις μόνος σου την browser υποδομή.
