Scrapy 2.17 समीक्षा: यह ब्राउज़र छोड़कर सीधे API से बात करता है

Scrapy को अक्सर “modern websites नहीं संभाल सकता” वाली कैटेगरी में डाल दिया जाता है, क्योंकि यह JavaScript नहीं चलाता। लेकिन यह सोच उलटी है। पेज को render न करना ही इसका असली idea है, और जब आप इसे काम करते देखते हैं, तो यह कमी नहीं बल्कि एक समझदार design लगने लगता है।

मैंने यह बात खुद एक ही run में साबित कर दी। मैंने एक JavaScript-rendered catalog fixture बनाया, Scrapy को उस page पर चलाया जिसे browser दिखाता, और 0 product cards मिले। फिर उसी spider को उस JSON endpoint पर भेजा जिसे वही page background में quietly call कर रहा था, और 8/8 items साफ़-सुथरे तरीके से मिल गए। वही tool, वही session, नतीजा बिल्कुल उल्टा — और इन्हीं दो numbers के बीच का फर्क इस पूरे review का सार है।

Scrapy वास्तव में क्या है — और क्या नहीं है

Scrapy एक Python framework है, जिसे websites को crawl करने और structured data निकालने के लिए बनाया गया है। यही इसकी maintainers की official framing भी है, जैसा कि overview docs में लिखा है, और इसका इस्तेमाल करने के बाद यह description बिल्कुल सही लगता है — इसमें marketing वाला कोई बढ़ा-चढ़ाकर दावा नहीं है। यह इतना पुराना और स्थापित हो चुका है कि जब कोई Python developer पूछता है कि serious लोग scraping किससे करते हैं, तो अक्सर यही पहला जवाब बनता है। इसका repository भी इसे साबित करता है: 07-07-2026 तक लगभग 62,981 GitHub stars (scrapy/scrapy), 11,773 forks और 590 open issues। BSD-3-Clause license, Python 3.10 या उससे नया, और मैंने जिस version को test किया वह 2.17.0 था, जो इन tests वाले ही सुबह release हुआ था — यानी इस run पर कोई पुराने-version वाला asterisk नहीं।

इसे newer AI-crawler crowd से अलग करने वाली सबसे अहम बात यह है: Scrapy by default HTTP-only है। कोई browser नहीं, कोई rendering engine नहीं। यह HTML को wire के जरिए fetch करता है, parser को देता है, और फिर CSS selectors या XPath की मदद से fields निकालने देता है। इसे limitation कहना आधा सच है और design को समझे बिना कही गई बात है। Scrapy का मूल idea यह है कि routine scrape के लिए headless Chrome चालू करना अक्सर गलत तरीका होता है — ज़्यादा समझदारी यह है कि page पहले से जो data request कर रहा है, उसे ढूँढकर सीधे उसी को hit किया जाए।

यह सिर्फ मेरी व्याख्या नहीं है। official dynamic content docs यही साफ़ तौर पर कहते हैं: पहले underlying data request को पहचानो और उसे दोहराओ; और जब ऐसा करना practical न हो, तभी fallback के रूप में headless browser इस्तेमाल करो। ज़्यादातर scrapers browser पहले खोलते हैं और API के बारे में सोचते ही नहीं। Scrapy default को उलट देता है।

मुख्य features, और हर design decision के पीछे की सोच

अंदरूनी level पर Scrapy कई हिस्सों का एक stack है, और हर हिस्सा आपके बारे में एक बात मानकर चलता है: आप developer हैं, और आप control चाहते हैं — कोई one-click wizard नहीं।

Spiders. आप एक class लिखते हैं, उसे start URLs देते हैं, और एक parse callback तय करते हैं जो items yield करता है या आगे के links follow करता है। No-code extractor की तुलना में यह ज़्यादा typing मांगता है — extraction rules आपको खुद लिखने होते हैं — लेकिन बदले में आपको यह पूरा control मिलता है कि क्या capture होगा और crawl अगली direction में कहाँ जाएगा।

Selectors. Parsing, parsel पर आधारित है, और उसके नीचे lxml काम करता है। CSS और XPath दोनों यहाँ first-class हैं, कोई बाद में जोड़ा गया feature नहीं। lxml की वजह से selection तेज़ रहती है और extraction code string-slicing के जंजाल की बजाय intent जैसा पढ़ता है।

Feed exports. Spider को किसी file की तरफ point कर दीजिए, और Scrapy आपके items को बिना extra plumbing के JSON, JSON Lines, CSV या XML में serialize कर देता है। मेरे run में एक static-catalog spider ने बिना किसी export code के JSON और CSV दोनों निकाल दिए — feed export वाली बात सिर्फ claim नहीं, सच में काम करती है।

AutoThrottle और crawl controls. Requests Twisted के जरिए asynchronously schedule होते हैं, और आपके पास concurrency limits, download delays, depth restrictions, adaptive rate-limiting के लिए AutoThrottle, और robots.txt compliance जैसे controls होते हैं। यही वे controls हैं जो बड़े crawl को server पर बेवजह बोझ डालने वाले हादसे में बदलने से बचाते हैं।

HTTP-only, लेकिन इसे feature की तरह समझिए. Browser न होने का मतलब है कम memory, ज़्यादा throughput, और rendering engine को संभालने की झंझट नहीं — बशर्ते आपका data साधारण HTTP से पहुँचने योग्य हो। और browser-first लोग जितना मानते हैं, उससे ज़्यादा बार ऐसा होता है।

Setup: वह dependency stack जिसकी कोई screenshot नहीं डालता

Installation बिल्कुल ordinary रहा, और इतने बड़े framework के लिए यह बात साफ़-साफ़ कहनी चाहिए। pip install Scrapy==2.17.0 ने macOS arm64 पर fresh virtual environment में binary wheels के साथ साफ़ install किया, बिना कुछ compile हुए अटकने के। रिपोर्ट करने लायक कोई drama नहीं था — और यही point है।

लेकिन देखें कि साथ में क्या-क्या आया। scrapy version -v ने बताया कि Scrapy 2.17.0, lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0, और cryptography 49.0.0 के ऊपर चल रहा था, और parsel, cssselect, तथा tldextract भी उसके साथ थे। यह एक असली footprint है — पूरे crawling framework जितना dependency load, कोई one-file HTML parser नहीं। इस machine पर सबके लिए wheels मौजूद थे, इसलिए install painless रहा। लेकिन दूसरे setups पर official docs अब भी platform-specific dependency friction की चेतावनी देते हैं, और historically cryptography और Twisted वाली layer पर दिक्कतें ज़्यादा आती रही हैं, इसलिए अगर आपका platform unusual है तो उसके लिए budget रखें। यहाँ setup smooth था; फिर भी जो install होता है उसका आकार जानना ज़रूरी है, क्योंकि आप एक framework ले रहे हैं और वह framework जितना heavy है, उतना तो होगा ही।

Hands-on: क्या चीज़ें अच्छी तरह चलीं

Install होने के बाद static path बिल्कुल साफ़ निकला। पूरा recall, कुछ भी नहीं छूटा।

Test	Result	Runtime
Local static catalog + pagination	12/12 products	0.557s
Static catalog CSV export	12 rows written	(same run)
Article extraction	title + 3/3 body paragraphs	0.416s
Crawl graph, DEPTH_LIMIT=2	depths 0/1/2 पर 11 pages	0.904s
Local 500 page	status 500 captured, no crash	0.424s
Books to Scrape (public)	20 products	2.053s
Quotes to Scrape spider (public)	12 quote items	3.465s

Static-catalog spider ने page one से page two तक pagination follow की और 12/12 expected records पकड़ लिए, फिर उसी pass में JSON और CSV दोनों में output दे दिया। सबसे interesting fixture article वाला है। Scrapy ने page को साफ़ Markdown में auto-clean करने की कोशिश नहीं की — इसके बजाय मैंने article fields को explicit selectors से target किया और nav/footer text को अलग-अलग fields में रख दिया, जिससे मुझे 3/3 body paragraphs मिले और boilerplate output में घुला-मिला नहीं। यही trade-off है: selectors आप लिखते हैं, और बदले में आपको वही मिलता है जो आपने माँगा — न कम, न ज़्यादा।

छोटे scale पर crawl control भी ठीक निकला। DEPTH_LIMIT=2, short download delay, per-domain concurrency, और robots.txt on रखने पर crawl graph ने depths 0, 1, और 2 में कुल 11 pages देखीं, और depth counting सही रही। Failure handling भी उतनी ही शांत थी। जानबूझकर बनाई गई 500 page एक structured item के रूप में लौटी, जिसमें handle_httpstatus_list के जरिए status 500 surface हुआ — कोई exception नहीं, run नहीं टूटा। Scrapy error status को ऐसे treat करता है जैसे वह spider logic के अंदर handle करने वाली चीज़ हो, न कि कोई ऐसा surprise जो crawl को गिरा दे।

Hands-on: JavaScript wall और उसके बगल वाला दरवाज़ा

अब वह result, जिसके इर्द-गिर्द यह review बना है।

मैंने Scrapy के HTTP fetcher को एक JavaScript-rendered catalog fixture पर चलाया। उसने source HTML डाउनलोड किया, 0 .product-card nodes पाए, और आगे बढ़ गया — क्योंकि उसने वह script चलाया ही नहीं जो उन cards को render करती। Public Quotes to Scrape JS page ने भी यही कहानी सुनाई: 0 rendered quote nodes। Test यहीं रोक दिया होता, तो आप Scrapy को इस decade की किसी भी चीज़ के लिए अनुपयुक्त मान लेते।

लेकिन यहीं मत रुकिए। वह JS catalog background में एक JSON API से भर रहा था, जैसा अक्सर होता है। मैंने उसी Scrapy spider को उस endpoint पर भेजा और 0.416s में 8/8 products मिल गए — कोई browser नहीं, कोई rendering नहीं, बस उसी URL को request किया जो page पहले से call कर रहा था, और वापस आए JSON को parse कर लिया।

यह side-by-side दिखाता है कि “reproduce the request” philosophy असल में क्या करती है। Rendered page सिर्फ एक decoy थी; असली data शुरू से एक API के पीछे बैठा था, और Scrapy का design आपको headless browser पर पैसा खर्च करने की बजाय सीधे उसी API तक पहुँचने की ओर धकेलता है। यह तेज़ है, हल्का है, और कम टूटता है — client-side DOM के ढेर पर निर्भर रहने की तुलना में एक API contract ज़्यादा stable चीज़ है। लेकिन इसमें एक catch है: काम manual है। आपको network tab खोलनी पड़ती है, request ढूँढनी पड़ती है, और उसके headers तथा params खुद दोहराने पड़ते हैं। Scrapy आपके लिए API खोज नहीं देगा; हाँ, जब endpoint मिल जाए तो उस पर hit करना बेहद आसान बना देता है।

दो सीमाएँ साफ़-साफ़ कहनी चाहिए। जब सचमुच कोई underlying request reproduce करने के लिए होती ही नहीं — यानी data पूरी तरह client-side rendering में baked हो और पीछे कोई API न हो — तब Scrapy को headless-browser integration चाहिए, जिसे आपको खुद wire करना होगा, और इस pass में मैंने उस path को test नहीं किया। और ऊपर जो कुछ भी है, वह छोटे fixtures और public demo pages पर चला है। मैंने 100 से 1,000 pages वाला crawl नहीं चलाया, इसलिए memory, throughput, या retry behavior को scale पर लेकर कोई दावा नहीं कर रहा — async core और crawl controls अच्छे संकेत हैं, लेकिन संकेत माप नहीं होते।

Pros और cons

Pros:

• HTTP-only design तेज़ और हल्का है — static recall 12/12 लगभग आधे सेकंड में, JSON API से 8/8 सिर्फ 0.416s में, browser overhead बिल्कुल नहीं।
• reproduce-the-request approach सच में काम करती है: JS page ने 0 दिए, लेकिन backing API से पूरे 8 items मिल गए।
• lxml-backed CSS और XPath selectors extraction code को readable और fast रखते हैं।
• JSON/CSV/XML feed exports के लिए अलग export plumbing लिखने की ज़रूरत नहीं।
• Explicit error handling — 500 एक handled status की तरह वापस आता है, crash की तरह नहीं।
• Mature crawl controls: concurrency, delays, depth limits, AutoThrottle, robots.txt।
• Permissive BSD-3-Clause license; current machine पर clean install।

Cons:

• Design के कारण JavaScript render नहीं करता — client-rendered page पर 0 nodes मिलते हैं, जब तक आप खुद API न ढूँढ लें।
• Underlying request ढूँढना manual है; Scrapy endpoint की ओर खुद इशारा नहीं करता।
• Dependency stack काफ़ी बड़ा है (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — यहाँ smooth रहा, लेकिन unusual platforms पर historically friction point रहा है।
• No-code या auto-extraction tools की तुलना में ज़्यादा code चाहिए; spiders आपको खुद लिखने और maintain करने होते हैं।
• मेरा testing small fixtures और demo sites तक सीमित था, बड़े crawls तक नहीं — scale reliability इस pass में साबित नहीं हुई।

यह किसके लिए है, और किसे आगे बढ़ जाना चाहिए

Scrapy उन developers के लिए है जो code-level control चाहते हैं और pages से ज़्यादा requests में सोचते हैं। अगर किसी slow JavaScript site को देखकर आपकी पहली सोच यह होती है, “इसके पीछे कहीं API होगी,” तो यह tool ठीक उसी instinct के लिए बनाया गया है। यह उन लोगों को reward करता है जो selectors लिखने, network tab पढ़ने, और अपनी extraction logic end-to-end संभालने में सहज हैं। Static sites, paginated catalogs, और discoverable JSON endpoint वाले किसी भी target के लिए यह तेज़ भी है और precise भी।

इसे छोड़ दीजिए — या कम से कम किसी और चीज़ के साथ pair कीजिए — अगर spider code लिखना और maintain करना आपका पसंदीदा काम नहीं है, या अगर आपके targets अपना data purely client-side render करते हैं और पीछे कोई reproducible request नहीं है, और आप खुद headless browser जोड़ना नहीं चाहते। और अगर आपकी चाहत बस इतनी थी कि किसी URL पर tool point करो और extraction rules लिखे बिना साफ़ structured output मिल जाए, तो Scrapy कभी उस काम के लिए बना ही नहीं था — और उसने कभी ऐसा pretend भी नहीं किया।

विकल्प, और Thunderbit कहाँ fit बैठता है

Web Data Extraction के लिए Thunderbit आज़माएँ

यह समझकर शुरुआत कीजिए कि आप किस चीज़ के लिए हाँ कह रहे हैं: एक free, open-source framework, जिसे आप खुद run और maintain करते हैं। Spiders, dependency stack, और हर site का data request ढूँढने का काम — सब आपकी जिम्मेदारी है। बदले में per-request कोई पैसा नहीं, सब कुछ in-house, और पूरी control मिलती है। बहुत सी teams के लिए यही सही फैसला है, और यह review किसी को इससे दूर करने के लिए नहीं है।

असल trade-off rendering और drift की problem में है, और Scrapy का जवाब है कि उसे आप solve करें: API ढूँढें, request दोहराएँ, और जहाँ API न हो वहाँ खुद browser wire करें। एक managed AI scraping API यह layer आपके सिर से उतार देता है। Technical readers के लिए यही slot Thunderbit के developer stack का है — AI scraping API + MCP server + CLI, न कि वह browser extension जो sales और ops वाले लोग इस्तेमाल करते हैं। POST /distill किसी page को साफ़, LLM-ready Markdown में बदल देता है; POST /extract आपके तय schema के अनुसार structured JSON लौटाता है; और दोनों JavaScript rendering, anti-bot, तथा dynamic content को server-side संभालते हैं — client-rendered case सहित, जहाँ Scrapy आपसे browser लेने को कहता है। AI agents और coding assistants के लिए MCP server भी है (जिसमें thunderbit_suggest_fields नाम का free tool है, जिससे आप खर्च करने से पहले page scope कर सकते हैं), और terminal, CI, या cron के लिए npx @thunderbit/thunderbit-cli वाला CLI भी मौजूद है।

फर्क quality का नहीं, ownership का है। Scrapy एक explicit engineering framework है: spider, pipeline, और JS strategy आप खुद maintain करते हैं, और per-call cost शून्य पर full control मिलती है। Thunderbit का stack render-and-extract layer को managed service की तरह सौंप देता है, इसलिए network tab में गहराई तक जाने की ज़रूरत नहीं रहती और आप per call भुगतान करते हैं। छोटा, code-first, और हर step खुद control करना पसंद है? तो Scrapy बेहतर fit है। सौ sites पर scale करना है और हर site के लिए request manually reproduce नहीं करनी? तो managed route उस पूरी category का काम हटा देता है।

इस broader field के लिए, ये benchmark write-ups आसपास के tools को cover करते हैं: full open-source scraper comparison, Colly की no-browser Go crawler review, और Scrapling की adaptive-selector review।

अंतिम फैसला

क्या आपको Scrapy इस्तेमाल करना चाहिए? हाँ — अगर आप ऐसे developer हैं जिन्हें control चाहिए और जो इस worldview को मानते हैं: पेज को render मत करो, उसके पीछे की request खोजो। Testing में यह philosophy बिल्कुल वादे के मुताबिक काम आई। एक JavaScript catalog ने HTTP fetcher को 0 cards दिए; उसे feed करने वाली JSON API ने उसी spider को पूरे 8 items सौंप दिए। Static extraction ने 12/12 पकड़े, article selectors ने 3/3 paragraphs को boilerplate से अलग रखा, crawl graph ने 11 pages में depth limit का पालन किया, और 500 crash बनने के बजाय handled status की तरह लौटी।

लेकिन दावों को सही scale पर रखिए। Scrapy JavaScript render नहीं करता, और API भी अपने आप नहीं खोजेगा — वह reflex आपको खुद बनाना होगा। Dependency stack framework जितना बड़ा है और unusual platforms पर चुभ सकता है, भले यहाँ सब साफ़ रहा। और मैंने fixtures तथा demo pages test किए हैं, कोई हजार-पेज crawl नहीं, इसलिए scale की कहानी को promising मानिए, साबित हुई हुई नहीं। इन सीमाओं के अंदर Scrapy उस quietly radical idea को सबसे अच्छी तरह अपनाता है: web page से होकर जाने का सबसे तेज़ रास्ता अक्सर web page से होकर नहीं जाता।

Web Data Extraction के लिए Thunderbit आज़माएँ Get Started Free

FAQs

क्या Scrapy JavaScript-rendered pages scrape कर सकता है? अपने default HTTP fetcher के साथ नहीं — मेरे test में JS fixture और public Quotes JS page दोनों पर 0 nodes मिले, क्योंकि यह browser चलाए बिना सिर्फ HTML डाउनलोड करता है। Intended path यह है कि page जो underlying data request करता है, उसे खोजकर सीधे उसी पर hit किया जाए; मेरे test में JS catalog के पीछे वाली JSON API ने पूरे 8 items दिए। जिन pages में कोई reproducible request नहीं होती, वहाँ आपको खुद headless browser जोड़ना पड़ता है।

“Reproduce the request” का मतलब असल में क्या है? ज़्यादातर dynamic pages अपना data background में किसी JSON API से लोड करते हैं, फिर उसे client-side render करते हैं। browser में यह होता हुआ देखने के बजाय, आप network tab खोलते हैं, API call ढूँढते हैं, और Scrapy को सीधे उसी पर point करते हैं। यह rendering की तुलना में तेज़ और ज़्यादा stable है — API contract, DOM की तुलना में कम बार टूटता है — लेकिन काम manual है, और Scrapy endpoint खुद नहीं ढूँढेगा।

क्या Scrapy install करना मुश्किल है? मेरे लिए तो नहीं था — macOS पर fresh venv में pip install Scrapy==2.17.0 बिना compilation errors के पूरा हो गया, और binary wheels इस्तेमाल हुए। लेकिन यह एक बड़ा stack pull करता है (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), और official docs अब भी कुछ systems पर platform-specific dependency friction की चेतावनी देते हैं, इसलिए अगर आपका platform unusual है तो उसे ध्यान में रखें।

Scrapy कौन-कौन से output formats support करता है? Feed exports out of the box JSON, JSON Lines, CSV, और XML को support करते हैं — spider को file की तरफ point कर दें और यह बिना extra code के items serialize कर देता है। मेरे run में एक spider ने एक ही pass में JSON और CSV दोनों बनाए। ध्यान रहे कि यह वही fields export करता है जो आपने select किए हैं; यह page को automatically Markdown में clean नहीं करता।

क्या Scrapy commercial use के लिए free है? हाँ, यह BSD-3-Clause license के तहत है, जो permissive भी है और commercial use के लिए friendly भी। जैसे हमेशा, इसे अपनाने से पहले repo पर current license ज़रूर verify करें, और अपने user-agent, proxy, और rate-limit choices जिम्मेदारी से रखें — capability का मतलब permission नहीं होता।