Scrapy ajunge adesea la categoria „nu poate gestiona site-uri moderne” pentru simplul fapt că nu rulează JavaScript. De fapt, percepția e pe dos. Ideea din spate este tocmai să nu randaze pagina, iar când vezi principiul pus în practică, începe să pară mai degrabă o alegere de design decât o lipsă de funcționalitate.
Mi-am demonstrat asta într-o singură rulare. Am construit un catalog de test randat cu JavaScript, am direcționat Scrapy către pagina pe care ar fi afișat-o un browser și am obținut 0 carduri de produs. Apoi am trimis același spider către endpoint-ul JSON pe care pagina îl apela discret în fundal și am primit 8/8 elemente, curate. Același instrument, aceeași sesiune, rezultate opuse — iar diferența dintre aceste două cifre este chiar miza acestei recenzii.
Ce este, de fapt, Scrapy (și ce nu este)
Scrapy este un framework Python pentru crawling de site-uri și extragerea de date structurate. Așa îl descriu și întreținătorii în documentația de prezentare, iar după ce l-am folosit, descrierea se confirmă — nu e nevoie să corectezi vreun exces de marketing. Este suficient de vechi și suficient de consacrat încât să fie răspunsul reflex atunci când un dezvoltator Python întreabă cu ce scot oamenii serioși date din site-uri, iar depozitul confirmă asta: aproximativ 62.981 de stele GitHub la 2026-07-07 (scrapy/scrapy), cu 11.773 fork-uri și 590 probleme deschise în aceeași zi. Licență BSD-3-Clause, Python 3.10 sau mai nou, iar versiunea testată de mine a fost 2.17.0, lansată chiar în dimineața în care am rulat testele — deci fără asterisc de versiune „aproape actuală”.
Iată linia care îl diferențiază de valul mai nou de crawlere AI: Scrapy funcționează, implicit, doar prin HTTP. Fără browser. Fără motor de randare. Ia HTML-ul prin rețea, îl trece printr-un parser și îți permite să extragi câmpuri cu selectori CSS sau XPath. Să numești asta limitare e pe jumătate corect, dar ratează complet ideea de design. Premisa Scrapy este că pornirea unui Chrome headless pentru o sarcină de scraping obișnuită este, de regulă, alegerea greșită — calea mai inteligentă este să găsești cererea de date pe care pagina o face deja și să o apelezi direct.
Această premisă nu e doar o interpretare pe care i-o atribui eu instrumentului. Documentația oficială despre dynamic content spune asta explicit: identifică și reproduce mai întâi cererea de date de bază, iar browserul headless devine soluția de rezervă doar atunci când reproducerea cererii nu este practică. Majoritatea instrumentelor de scraping deschid browserul din start și nici nu se mai gândesc la API. Scrapy inversează această pornire implicită.
Funcționalități esențiale și deciziile de design din spatele lor
În interior, Scrapy este o suită de componente care pornește de la aceeași presupunere despre tine: ești un dezvoltator care vrea control, nu un asistent cu un singur click.
Spiders. Scrii o clasă, îi dai URL-urile de start și definești un callback parse care returnează elemente sau urmărește alte linkuri. E mai mult de scris decât într-un extractor no-code — regulile de extracție îți aparțin — dar în schimb ai control exact asupra a ceea ce se capturează și a direcției în care continuă crawl-ul.
Selectors. Parsarea se bazează pe parsel, care folosește lxml dedesubt. CSS și XPath sunt tratate egal, nu ca adăugiri separate. Sprijinul din lxml explică de ce selecția rămâne rapidă și de ce codul de extracție se citește ca o intenție clară, nu ca un mozaic de tăieri de șiruri.
Feed exports. Direcționezi un spider către un fișier, iar Scrapy îți serializează elementele în JSON, JSON Lines, CSV sau XML fără să mai scrii infrastructură suplimentară. În rularea mea, un spider pentru un catalog static a generat atât JSON, cât și CSV fără să scriu nicio linie de cod dedicată exportului — povestea despre feed export este reală și funcționează exact cum promite.
AutoThrottle și controale de crawl. Cererile sunt programate asincron pe Twisted, iar tu primești limite de concurență, întârzieri între descărcări, restricții de adâncime, AutoThrottle pentru limitare adaptivă a ratei și respectarea robots.txt. Aceste controale sunt cele care împiedică un crawl amplu să se transforme într-un incident de tip „am bombardat serverul”.
Doar HTTP, spus altfel ca avantaj. Fără browser înseamnă memorie redusă, randament mare și niciun motor de randare pe care să-l întreții — atâta timp cât datele dorite sunt accesibile prin HTTP simplu. Iar, mai des decât presupune publicul „browser-first”, chiar sunt.
Instalare: stiva de dependențe pe care nimeni nu o pune în capturi de ecran
Instalarea a fost lipsită de evenimente, iar pentru un framework de această dimensiune merită spus clar. pip install Scrapy==2.17.0 s-a terminat fără probleme într-un mediu virtual nou pe macOS arm64, cu wheel-uri binare, fără compilări care să se blocheze. Nimic spectaculos de raportat — și tocmai acesta e punctul.
Totuși, uită-te ce a venit la pachet. scrapy version -v a raportat Scrapy 2.17.0 rulând pe lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 și cryptography 49.0.0, la care se adaugă parsel, cssselect și tldextract. E o amprentă serioasă — o stivă completă pentru crawling, nu un simplu parser HTML într-un singur fișier. Pe această mașină, existau wheel-uri pentru toate și instalarea a rămas fără dureri. Pe alte configurații, documentația oficială avertizează încă asupra unor fricțiuni legate de dependențe specifice platformei, iar istoric problemele apar mai ales în zona cryptography și Twisted, așa că merită să bugetezi timp dacă lucrezi pe un sistem neobișnuit. Aici instalarea a mers lin; dimensiunea a ceea ce se instalează rămâne totuși relevantă înainte să te angajezi, pentru că primești un framework și plătești greutatea unui framework.
Teste practice: ce a funcționat
După instalare, calea statică a mers impecabil. Recunoaștere completă, nimic pierdut.
| Test | Rezultat | Durată |
|---|---|---|
| Catalog static local + paginare | 12/12 produse | 0.557s |
| Export CSV pentru catalog static | 12 rânduri scrise | (aceeași rulare) |
| Extragere articol | titlu + 3/3 paragrafe din corp | 0.416s |
| Grafic de crawl, DEPTH_LIMIT=2 | 11 pagini pe adâncimile 0/1/2 | 0.904s |
| Pagina locală 500 | status 500 capturat, fără crash | 0.424s |
| Books to Scrape (public) | 20 produse | 2.053s |
| Spider Quotes to Scrape (public) | 12 elemente citat | 3.465s |
Spiderul pentru catalogul static a parcurs paginarea de la pagina unu la pagina doi și a capturat 12/12 înregistrări așteptate, apoi le-a scris ca JSON și CSV în aceeași trecere. Fixture-ul cu articolul este cel care merită analizat atent. Scrapy nu a încercat să curețe automat pagina într-un Markdown ordonat — în schimb, mi-a permis să țintesc câmpurile article cu selectori expliciți și să păstrez textul de navigare și footer în câmpuri separate, astfel încât am obținut 3/3 paragrafe din corp, iar conținutul generic a rămas izolat, nu amestecat în rezultat. Acesta este schimbul: scrii selectori, obții exact ce ai cerut și nimic în plus.
Controlul crawl-ului s-a dovedit corect la scară mică. Cu DEPTH_LIMIT=2, o întârziere scurtă între descărcări, concurență per domeniu și robots.txt activ, graficul de crawl a văzut 11 pagini la adâncimile 0, 1 și 2, iar numărarea adâncimii a funcționat corect. Gestionarea eșecurilor a fost la fel de banală, în sens bun. Pagina intenționat 500 a revenit ca un element structurat cu status 500 expus prin handle_httpstatus_list — fără excepție, fără rulare întreruptă. Scrapy tratează un status de eroare ca pe ceva ce gestionezi în logica spiderului, nu ca pe o surpriză care doboară crawl-ul.
Teste practice: peretele JavaScript și ușa de alături
Acum ajungem la rezultatul pe care se sprijină această recenzie.
Am îndreptat fetcherul HTTP din Scrapy către un catalog de test randat cu JavaScript. A descărcat HTML-ul sursă, a găsit 0 noduri .product-card și a mers mai departe — pentru că nu a rulat niciodată scriptul care ar fi desenat acele carduri. Și pagina publică Quotes to Scrape JS a spus aceeași poveste: 0 noduri de citat randate. Dacă te oprești aici, ai fi tentat să respingi Scrapy ca fiind nepotrivit pentru orice site construit în ultimul deceniu.
Dar nu te opri aici. Catalogul JS era alimentat în fundal de un API JSON, ca majoritatea aplicațiilor de acest tip. Am trimis același spider Scrapy către acel endpoint și am obținut 8/8 produse în 0.416s — fără browser, fără randare, doar o cerere către URL-ul pe care pagina îl apela deja și parsarea JSON-ului întors.
Această comparație alăturată rezumă filosofia „reproduce cererea” la scară mică. Pagina randată era un paravan; datele stăteau de la început în spatele unui API, iar designul Scrapy te împinge să apelezi direct acel API, în loc să plătești pentru un browser headless care doar urmărește cum se construiește pagina. Este mai rapid, mai ușor și se defectează mai rar — un contract API este, de obicei, mai stabil decât o grămadă de DOM construită în client. Dar există și reversul: trebuie să faci munca manuală. Trebuie să deschizi tab-ul de rețea, să găsești cererea și să reproduci singur antetele și parametrii. Scrapy nu descoperă API-ul pentru tine; doar îl face foarte ușor de apelat după ce l-ai găsit.
Două limite, spuse clar. Când într-adevăr nu există nicio cerere de bază care să poată fi reprodusă — datele sunt generate exclusiv în client, fără niciun API în spate — Scrapy are nevoie de o integrare cu browser headless pe care trebuie să o configurezi tu, iar în această trecere nu am testat acel traseu. Și tot ce este prezentat mai sus a rulat pe fixture-uri mici și pagini demo publice. Nu am rulat un crawl de 100 până la 1.000 de pagini, așa că nu fac nicio afirmație despre memorie, randament sau comportamentul la retry la scară mare — nucleul asincron și controalele de crawl sunt semnale bune, dar un semnal nu este o măsurătoare.
Avantaje și dezavantaje
Avantaje:
- Designul doar pe HTTP este rapid și ușor — 12/12 recunoaștere statică în aproximativ o jumătate de secundă, 8/8 dintr-un API JSON în 0.416s, fără overhead de browser.
- Abordarea „reproduce cererea” chiar livrează: o pagină JS care a returnat 0 a cedat toate cele 8 elemente prin API-ul din spate.
- Selecțiile CSS și XPath bazate pe
lxmlpăstrează codul de extracție clar și rapid. - Feed exports către JSON/CSV/XML fără să scrii infrastructură de export.
- Gestionare explicită a erorilor — un 500 revine ca status pe care îl prinzi, nu ca un crash.
- Controale mature de crawl: concurență, întârzieri, limite de adâncime, AutoThrottle, robots.txt.
- Licență BSD-3-Clause permissivă; instalare curată pe un sistem actual.
Dezavantaje:
- Nu randaze JavaScript prin design — 0 noduri pe o pagină randată în client până găsești singur API-ul.
- Găsirea cererii de bază se face manual; Scrapy nu te duce la endpoint.
- Stivă de dependențe consistentă ca volum (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — a mers bine aici, dar istoric poate crea fricțiuni pe platforme ieșite din tipar.
- Mai mult cod decât instrumentele no-code sau cele cu extracție automată; spider-ele trebuie scrise și întreținute de tine.
- Testele mele au acoperit fixture-uri mici și site-uri demo, nu crawl-uri mari — fiabilitatea la scară rămâne nedemonstrată în această rundă.
Pentru cine este și cine ar trebui să treacă mai departe
Scrapy este pentru dezvoltatorii care vor control la nivel de cod și gândesc în cereri, nu în pagini. Dacă reacția ta instinctivă la un site JavaScript lent este „sigur există un API pe undeva pe aici”, instrumentul este construit exact pentru acest reflex. Îi răsplătește pe cei confortabili cu scrierea de selectori, cu citirea tab-ului de rețea și cu asumarea logicii de extracție cap-coadă. Pentru site-uri statice, cataloage paginated și orice lucru alimentat de un endpoint JSON identificabil, este rapid și precis.
Treci mai departe de el — sau, cel puțin, combină-l cu altceva — dacă nu vrei să-ți petreci timpul scriind și menținând cod de spider sau dacă țintele tale își randazează datele strict în client, fără o cerere reproductibilă, iar tu nu vrei să atașezi singur un browser headless. Și dacă visul era să dai un URL unui instrument și să obții ieșire structurată curată fără să scrii reguli de extracție, asta nu a fost niciodată treaba Scrapy și nici nu s-a pretins altceva.
Alternative și unde se potrivește Thunderbit
Încearcă Thunderbit pentru extragerea datelor web
Începe cu ce presupune utilizarea: un framework gratuit, open-source, pe care îl rulezi și îl întreții singur. Tu deții spider-ele, stiva de dependențe și munca de identificare a cererii de date pentru fiecare site. În schimb, nu plătești nimic per cerere, păstrezi totul în interior și ai control complet. Pentru multe echipe, acesta este exact răspunsul corect, iar recenzia de față nu încearcă să convingă pe nimeni de contrariul.
Compromisul apare în problema randării și a deviației de conținut, iar răspunsul Scrapy este că tu rezolvi asta: găsești API-ul, reproduci cererea și tratezi cazul fără API conectând singur un browser. Un API gestionat de scraping AI scoate însă acest strat de pe umerii tăi. Acolo se poziționează Thunderbit pentru cititorii tehnici — un API de scraping AI plus server MCP plus CLI, nu extensia de browser folosită de echipele de vânzări și operațiuni. POST /distill transformă o pagină în Markdown curat, gata pentru LLM; POST /extract returnează JSON structurat pe baza unei scheme definite de tine; iar ambele tratează randarea JavaScript, anti-bot și conținutul dinamic pe partea de server — inclusiv cazul randat în client, în care Scrapy îți cere să apelezi la un browser. Există un server MCP pentru agenți AI și asistenți de codare (cu funcția gratuită thunderbit_suggest_fields, ca să delimitezi o pagină înainte să cheltuiești ceva), precum și un CLI prin npx @thunderbit/thunderbit-cli pentru terminal, CI sau taskuri cron.
Diferența nu ține de calitate, ci de proprietate. Scrapy este un framework de inginerie asumat: tu întreții spider-ul, pipeline-ul și strategia pentru JavaScript, iar la schimb primești control total fără cost per apel. Stiva Thunderbit preia stratul de randare și extracție ca serviciu gestionat, astfel încât sari peste explorarea tab-ului de rețea și plătești per apel. Mic, orientat pe cod și îți place să controlezi fiecare pas? Controlul oferit de Scrapy este mai potrivit. Trebuie să scalezi pe o sută de site-uri și nu vrei să reproduci manual o cerere pentru fiecare? Ruta gestionată elimină complet această categorie de muncă.
Pentru contextul mai larg, aceste comparații acoperă și „vecinii”: compararea completă a scraperelor open-source, recenzia crawlerului Go fără browser Colly și recenzia Scrapling pentru selectori adaptivi.
Verdict
Ar trebui să folosești Scrapy? Da — dacă ești dezvoltator și vrei control și dacă accepți filozofia: nu randaza pagina, ci găsește cererea din spatele ei. În testele mele, această filozofie a livrat exact ce promite. Un catalog JavaScript a întors 0 carduri pentru fetcherul HTTP; API-ul JSON care îl alimenta a oferit toate cele 8 elemente aceluiași spider. Extragerea statică a ajuns la 12/12, selectorii pentru articol au păstrat 3/3 paragrafe curate, graficul de crawl și-a respectat limita de adâncime pe 11 pagini, iar un 500 s-a întors ca status gestionat, nu ca prăbușire.
Totuși, trebuie dimensionate corect afirmațiile. Scrapy nu randaze JavaScript și nu îți va găsi API-ul de unul singur — acel reflex trebuie să îl construiești tu. Stiva de dependențe este una de framework și poate crea probleme pe platforme neobișnuite, chiar dacă aici instalarea a fost curată. Iar eu am testat fixture-uri și pagini demo, nu un crawl de o mie de pagini, așa că tratează povestea despre scală ca fiind promițătoare, dar nedemonstrată. În aceste limite, Scrapy este instrumentul care se angajează cel mai bine într-o idee liniștit radicală: cea mai rapidă cale printr-o pagină web nu este, de obicei, prin pagină.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
Întrebări frecvente
Poate Scrapy să extragă pagini randate cu JavaScript?
Nu cu fetcherul său HTTP implicit — în testele mele a returnat 0 noduri atât pe un fixture JS, cât și pe pagina publică Quotes JS, deoarece descarcă HTML-ul fără să ruleze un browser. Traseul dorit este să identifici cererea de date de bază pe care o face pagina și să o apelezi direct; în testul meu, API-ul JSON din spatele unui catalog JS a livrat toate cele 8 elemente. Pentru pagini fără o cerere reproductibilă, trebuie să conectezi singur un browser headless.
Ce înseamnă, de fapt, „reproduce cererea”?
Majoritatea paginilor dinamice își încarcă datele dintr-un API JSON în fundal, apoi le randazează în client. În loc să rulezi un browser ca să urmărești procesul, deschizi tab-ul de rețea, găsești apelul către API și direcționezi Scrapy direct către el. Este mai rapid și mai stabil decât randarea — un contract API se rupe mai rar decât DOM-ul — dar este muncă manuală, iar Scrapy nu îți va găsi endpoint-ul.
Este greu de instalat Scrapy?
Pentru mine a fost simplu — pip install Scrapy==2.17.0 s-a terminat fără erori de compilare într-un venv nou pe macOS, folosind wheel-uri binare. Dar aduce cu el o stivă consistentă (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), iar documentația oficială avertizează încă asupra fricțiunilor de dependență specifice platformei pe unele sisteme, deci merită să ții cont de asta dacă lucrezi pe ceva neobișnuit.
Ce formate de ieșire acceptă Scrapy?
Feed exports acoperă JSON, JSON Lines, CSV și XML direct din start — direcționezi spider-ul către un fișier și îți serializează elementele fără cod suplimentar. În rularea mea, un spider a produs atât JSON, cât și CSV într-o singură trecere. Reține că exportă câmpurile selectate de tine; nu curăță automat pagina în Markdown.
Este Scrapy gratuit pentru uz comercial?
Da, are licență BSD-3-Clause, deci este permisiv și prietenos cu utilizarea comercială. Ca întotdeauna, verifică licența actuală în repo înainte să construiești pe baza lui și păstrează deciziile legate de user-agent, proxy și rate-limit în limite responsabile — faptul că poți, nu înseamnă că și trebuie.
