Live data from Hacker News

The State of Web Scraping in 2021

mihaisplace.blog

31–40 of 132 posts

Re: The State of Web Scraping in 2021

#31

If you're familiar with Go, there's Colly too [1]. I liked its simplicity and approach and even wrote a little wrapper around it to run it via Docker and a config file: https://gotripod.com/insights/super-simple-site-crawling-and... [1] http://go-colly.org/

+1 for Go. Its easy concurrency makes it an awesome language for web scraping.

The go-colly framework was a bit too restrictive for my needs, but its very easy to build something on top of the standard lib's net/http, its cookiejar, and a third party library called goquery (afaik go-colly uses this too).

Fun Fact: We were scraping something from an apparantly zero rate limits azure blob container, and we had to enumerate around a million URLs daily (didn't know which URLs actually existed so we guessed an offset and enumerated from there, also we had to do it at a fixed time daily). We had proxys at our disposal but didn't need them cause the blob container did not rate-limit.

I wrote the scraper in Go, but a friend wrote it in Rust. Using Go was fast enough, satisfying all our requirements, but it turned out that the Rust one was 3-5 times faster. I tried to improve the Go scraper's speed by tweaking net/http transport's parameters, increasing workers, removing all NOFILE limits from SystemD and tried to profile and remove the low hanging speed issues. Nothing reduced the gap. Then I replaced the net/http client with valyala/fasthttp (another http implementation in Go) , which made it as fast as or slightly faster than the Rust one which was using the reqwest crate as http client.

Re: The State of Web Scraping in 2021

#32

If you're familiar with Go, there's Colly too [1]. I liked its simplicity and approach and even wrote a little wrapper around it to run it via Docker and a config file: https://gotripod.com/insights/super-simple-site-crawling-and... [1] http://go-colly.org/

I used this library to get familiar with Go. It is indeed very powerful and really easy to create a scraper.

My main concerns though were about testing. What if you want to create tests to check if your scraper still gets the data we want? Colly allows nested scraping and it's easy to implement but you have all your logic into one big function, making it harder to test.

Did you find a solution to this? I'm considering switching to net/http + GoQuery only to have more freedom.

Re: The State of Web Scraping in 2021

#33
post #14

What kind of stuff are people needing to scrape?

I scrape multiple government sites to fill all the data for https://www.quienmerepresenta.com.mx/

It tells you who is your governor, local/federal representative, senator and municipal president. Each representative lives on a different website so I wrote scrappers for each one.

Re: The State of Web Scraping in 2021

#36
post #19

Earlier quoted context omitted.

so will Google's freezing of the UA lead to less ability to web scrape for the non big company scrapers out there?

Sorry can you please elaborate what is Google doing?

sorry, I thought it was a well known thing here given the various discussions over past year or so https://groups.google.com/a/chromium.org/g/blink-dev/c/-2JIR...

on edit: so I'm thinking as there will only be one UA floating around then, sure, older UAs can exist, but those become progressively more suspicious.

Re: The State of Web Scraping in 2021

#37

Is there open source software that can extract the "content" part of a given page cleanly? I'm thinking about what the reader mode in browsers can do as an example, where the main content is somehow isolated and displayed.

I believe the main library for reader mode is called readability. I played around with a python implementation a while back. Just pipe in your raw html as part of the process. It's good, but not flawless. If I remember correctly, it included some quotes and image text as part of the body for the site I tried it on.

Re: The State of Web Scraping in 2021

#38
post #2

Nowadays is more and more common for websites to have some kind of rate limiting middleware such as rack attack for ruby. It would be interesting to explore the strategies to deal with it.

Why not just lower the crawl rate? My search engine crawler visits tens of million documents in a week at a rate of 1 doc/second, but a few hundred different domains at the same time.

Going as low as 0.2 dps could easily be doable I think.

Re: The State of Web Scraping in 2021

#39

Why no mention of selenium? Is it not cool anymore? I have never heard of mechanicalsoup: is it selenium replacement?

> is it selenium replacement

No completely different use case. Selenium is browser automation. Mechanical soup/Mechanize/Robobrowser are not actually web browsers, they have no javascript support either. They're python libraries that can simulate a web browser but doing GET requests, storing cookies across requests, filling http POST forms, etc.

The downside is that they don't work with websites which rely on JavaScript to load content. But if you're scraping a website like that, then it might be easier and way way faster to analyze web requests using dev tools or mitmproxy, then automating those API calls instead of automating a browser.

Re: The State of Web Scraping in 2021

#40

Why no mention of selenium? Is it not cool anymore? I have never heard of mechanicalsoup: is it selenium replacement?

Selenium is famously unreliable, so a lot of people have been replacing it with headless chrome where they can.

Interesting. I was about to start on some web automation and so far I've had hammered into my head that Selenium is the 'language of the internet' or something along those lines.

What would be a better solution, if you have any to recommend?

Post reply on HN