What do you do when you're working with an amazing web application that, for whatever reason, doesn't have an API?
One option is to say, gee, I wish that site had an API and just give up.
Or you could use Scrapey, an open source web scraping framework from Pablo Hoffman and scrapinghub.com, and create your own API.
On episode 50 of Talk Python To Me, we'll talk about how to do this, when it makes sense, and even when it's allowed.
This episode has been recorded February 16th, 2016.
Welcome to Talk Python To Me, a weekly podcast on Python.
The language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
Hey, everyone.
Thanks for joining me today.
We have a great interview on tap with Pablo Hoffman.
I want to give you a quick Kickstarter update before we get to that, though.
There are just three days left to join the course via Kickstarter.
Get a big discount while you're at it.
Of course, it'll be for sale afterwards, but not at the Kickstarter prices.
The students who have had early access have had really positive things to say.
Here's just a taste.
This is by far the best Python course I've done to date.
Clear explanations, good apps that incorporate the concepts of particular sessions, and follow
up on core concepts.
The course is very engaging with a little humor, which makes it much easier to dedicate time
to following along.
If you're looking for an easy to follow, enjoyable Python course, back this project now.
Get comfortable and enjoy.
Thanks, Andy.
You can check it out at talkpython.fm/course.
Now let's talk about web scraping.
Pablo, welcome to the show.
Thank you, Michael.
Thanks for having me here.
Yeah, we got some really cool stuff to talk about.
Web scraping, open source businesses.
We'll talk a little bit of Python 3, maybe.
All sorts of cool things.
But before we dig into them, let's talk about your story.
How did you get into Python and programming?
All right.
So I met Python when I was in college in 2004, and I immediately fell in love with it, with
the simplicity and the structure of the syntax.
Back then, I was doing a lot of subjects in college, but I always tried to find an opportunity
to use Python for whatever.
I would invent a lot of crazy, just useless stuff just to be able to use Python for it.
Before Python, I used my past.
I used PHP, but I don't regret anything I did.
But yeah, I come from that background, more sysadmin, intranet web application background, sort
of natural flow for me.
I started working on Python in 2014, introduced by a colleague in college.
And I never looked back.
And yeah, it was only in 2007 that I was able to start a company working solely on Python.
So I had to wait three years.
But you've made it.
You finally made it.
Yeah, yeah, yeah.
Absolutely.
And I'm still here almost 10 years later working pretty much exclusively with Python and enjoying
every moment of it.
Yeah, that's really cool.
What continues to surprise me about Python is here's a language in the ecosystem that's
25 plus years old and seems to be becoming more popular and growing faster, even though
it's not like something new that just sprung on the scene.
So yeah, I think we're in a good place.
Yeah, yeah.
I believe it's a lot of combination of things, right?
And the community certainly is one of the key aspects of Python, in addition to the language
being beautiful and elegant by itself.
So a lot of things that come together for that to happen.
Yeah, I totally agree.
So we're going to talk about web scraping.
There's a whole variety of listeners.
Some of them go, oh, yeah, web scraping.
I did that back in, you know, whatever.
But a lot of people maybe don't really understand or are familiar with this.
So maybe give me the background on what is web scraping?
Why do we do this?
How does it work?
Right.
So there's a bunch of information everywhere in the web right now and has always been and
continues to be and will.
The information is growing in presenting amounts.
And so there's a natural need for extracting and using that information for all kinds of purposes.
But you can't just take what's on a web page and use it as is.
You need to transform it, extract it and transform it in order to apply whatever.
You need to apply to it.
And that is where web scraping comes into play.
And data is great.
Data is beautiful.
There's a lot of things that you can do with data once you have it in a format that you can manipulate.
And so that's where web scraping discipline sits.
And given the increasing and ever increasing amount of data in web pages in a structure form,
web scraping is here to stay definitely and it's going to continue growing.
My interest in web scraping came shortly after I met Python in college.
So there was this new site ecosystem in my country here in Uruguay where newspapers had just came online but didn't really get it.
So they posted the news there.
However, they seemed too pleased.
And the information there wasn't really accessible.
There was no commenting possibilities.
So I started off creating a new site that aggregated all the newspaper, the local media available then, which was really short.
And sort of put it together in a single news aggregator with RSS feeds.
Nice.
So it was just like a very early simple version of Google News type thing?
Yeah, Google News existed back then, but Uruguay was completely ignored by them, right?
Even up to today, we don't have Uruguay in Google News supported country.
But you can think of it, yeah, as a Google News with custom extractors for each site.
So I ended up building this project.
It was called NotiUI because Noticias and Uruguay, the two words, combined together.
I built it in Python.
The extractors, as I was live, started getting some attention.
It was after that project that I run my extra time completely.
It's a hobby project that I got noticed by a company here in Uruguay that introduced me to the company that I later joined to work full-time on Python.
I eventually created Scrappy and open-sourced it.
So, yeah, it's funny how you can connect the dots after everything.
Yeah, you can connect the dots looking backwards, but not forwards, right?
Yeah, forward now.
That's really cool.
Before we move on to Scrappy, ideally, everything, all the information should be free.
Maybe there should be, like, an HTTP JSON service, we could access, or, God forbid, like an XML, so WCF service or something.
But a lot of times, even that is not available, right?
There's just, it's on the web, and technically you can get the text, but nobody's built an API, right?
And that's really where web scraping kind of comes in, is when you know that it is accessible, but there's no structured API for it, right?
Exactly. And as a future of web scraping, I see scraping evolving a lot with a lot more machine learning incorporated directly at the early extraction phase,
so that you can turn a website page into an API as quick as possible without requiring manual coding or manual intervention.
That's really interesting, because the web scraping that I know is, you say, I'm looking for this information, and maybe here's a CSS selector that I could go against the page, and then I'll grab it.
But that's not machine learning, right?
That's the web scraping that most people are familiar with.
But once you need to scale to a lot of websites that simply doesn't work, it was the scraping that Scrappy was built for.
And because of this need to scale to maintaining a lot of website instructors in a common way and more consistent, unified fashion is that this Scrappy idea came to light.
Because otherwise, after you're maintaining a couple of dozens of sites, you're fighting with just your own code infrastructure rather than writing the expats or the CSS selectors.
That's the easy part, right?
That's one of the reasons why we came up with Scrappy.
Very cool.
So why don't you tell us what it is?
Scrappy started as an initiative to build a lot of web scrapers more easily and relieve the pain of maintaining them.
Because Scrappy was built in an environment where we had to maintain hundreds of spiders, as we call them.
And you need to have a certain structure in the code, certain conventions in place, so that when someone else joins the team, a new developer joins the team,
and starts developing new spiders, they don't need to go through learning a lot of intricate internals about how the spiders are supposed to work and the rest of the infrastructure.
So what Scrappy does is it tries to factor out the common things that you do when you write web scrapers and separate them from the actual extraction rules or expats and CSS selectors that you will type for each website.
So that you have all the rest of the site.
So that's where Scrappy excels, really.
And compared to other ad hoc solutions, like combining requests with beautiful soup, which have great libraries and they do a great job.
And maybe if you're writing a single structure for a single site, you wouldn't find much difference between using one or the other.
But if your project involves maintaining a spider for hundreds or even dozens of websites, you'll see these conventions that Scrappy proposes very welcome advantages.
So in a way, it's a framework.
It's not a library.
So it's not that it doesn't get in the way.
It does get in the way.
But for good reasons.
It tries to impose some common practice and good practices and mechanisms so that you don't have to go through the typical journey of first doing this simple stuff and then realizing that you needed something more complex only to end up implementing a smaller version of what Scrappy is.
That's a really interesting comparison with the other ones.
I want to have you maybe quickly walk people through the API.
But before we kind of get off the beginning of it, can you just tell me the history?
You said it came out of your work at this company.
Like, did you actually get permission to kind of extract that framework out or did you leave that company and rebuild it with your knowledge from there?
What year is that?
This company, MyDeco, was a furniture aggregator in the UK.
I joined them in 2007.
And when I joined MyDeco, there was a lot of parts of Scrappy already built there.
Like the core framework, the downloader, and the more important internals were already in place.
It was working fine already.
You really noticed that there was an improvement over how you will go about writing ad hoc web crawlers.
So I started in this Scrappy department in MyDeco.
And I noticed that there was a huge potential for releasing this to the wild and making other people benefit from it.
By then, I was already a hardcore open source fan.
And I've been following many open source projects and open source practices.
And I was looking for an opportunity to get involved and to release my own open source project.
Pretty much like I was waiting for opportunities to pop up on or to work on Python in 2004.
I was looking for open source opportunities in 2007 as well.
Yeah, fortunately, the people in charge of MyDeco, the technical part of MyDeco, were quite aligned with open source as well.
Quite fans themselves.
So that makes things a lot easier.
So we didn't have much problems convincing the board.
Well, they didn't have much problems convincing the board to allow us to open source that part.
What happened afterwards is that there was a lot of work on my side and a couple of guys that worked in my company back then.
They're working on ironing out, factoring out the common code and packaging in a way that makes sense for external developers to digest and use.
That's cool.
And when you did that, basically you released this open source.
Did this company like take it back and sort of start using it?
Or did they just kind of go along in a parallel path?
We started from something already built, right?
It's not like we decided to build an open source project and started from scratch there.
We had a system already working and we wanted to take certain core parts of it and open source it.
This was a challenge because there was a lot of dependencies in the code that took us some time to factor out.
But at no point we wanted to diverge or fork into two separate projects.
I never even considered it to go that path.
But I think it was crucial and important that we remain always in sync because MyDeco was the main user of Scrappy and the feedback loop was crucial for Scrappy to succeed.
If you look at it, it makes no sense to build an open source.
At least if you want to build a successful open source project, for me, you need to have successful companies or users using it, right?
Just don't build it in abstract unless it's an academic thing, of course.
This allowed us to grow Scrappy.
The beginning was a lot of de-integration work, to put it somehow, so that all the crawlers at this company remain running while we move stuff to a state where it could be open source.
And sure, a few spiders broke here and there, but yeah, we learned along the process how to improve spider testing, if you will, for when you make changes in a framework.
And that's also part of Scrappy as one of the features.
One thing that's cool about the spiders is you can rerun them against the same source if you have to, right?
You can check if they extract the same data, and that's how you actually check that the spider remains working.
You need to find a way to do it fast enough if you have thousands of them.
That's just one caveat to keep in mind, but yeah.
Sure, sure.
What was the version of Python that you started on?
It was 2.5 back then.
It was only a year or two ago that we dropped support for 2.5 in Scrappy.
And yeah, right now we're 2.7 and almost finishing support for Python 3.
Actually, support is finished, and it's in beta mode now in the last version of Scrappy, which makes me very proud.
Yeah, I just saw an announcement.
What was that, two weeks ago that you guys announced that you are now officially beta in Python 3?
I had a project where I needed to do some web scraping, and I ended up going the request plus beautiful soup for direction because I didn't want to be painted into the corner of halving to do Python 2.
And I'm like, oh, if I go down Scrappy, the path maybe.
But so I was like, oh, yes, that's great when that came out.
So congratulations.
Was it a lot of work?
It was because it's a moderately big project.
But we decided to really, really prioritize this because we realized that maybe a bit late, if you will, that people were actually not using or leaving Scrappy because of the lack of Python 3 support.
But I'm glad that we're on it now and we have it there.
Yeah, that's fantastic.
Congrats.
Thank you.
Cool.
So let's talk about the API a little bit.
If you go to Scrappy.org, right there you've got a couple of code snippets showing you how you can use it and so on.
One of your examples is if I go to like a blog, I want to go grab all the links that are categories.
Can you maybe just talk us through what that looks like?
Yeah.
You want me to go through the code that is on Scrappy.org?
Not exactly.
Just tell me what, like kind of how do I get started with Scrappy, basically.
So Scrappy has a pretty good tutorial in the base documentation that I recommend as a starting point.
I always recommend a starting point.
The idea is that you should, unless you have complex needs, you should be enough writing a spider,
which can be just a couple of lines as it's shown in Scrappy.org website.
The spider API itself is really simple in the sense that you have this, well, class to group all things related to the spider,
where the class has methods that are called.
These are essentially callbacks that are called with responses or web pages that are retrieved from the web,
that are delivered to these callbacks.
And then these callbacks process the response in however they need, and then return items or subsequent requests to follow.
That's the very basic idea of Scrappy API in its best.
So using this simple API, you can build a lot of things on top of it.
I love APIs that are really simple at the bottom and that allows you to do a lot.
This is the most basic spider API, and all spiders in Scrappy will follow this one.
But then on top of it, there's variations and improvements, like something called crawl spider,
that will allow you to set up some rules for URLs that should be followed by the spider.
So you set up some class attributes with these rules and start URLs that they should start crawling from.
And the spider automatically follows them and calls certain callbacks when the URLs fit a certain pattern.
This type of spider is very useful for, for example, crawling a retailer, an e-commerce site,
where you want to extract the product data for certain URLs.
And many sites will follow this pattern of having a certain pattern of URLs to follow
and certain rules to extract the product data out of the pages.
So all that internally is built with a simple API of receiving a response and returning requests to follow
and eat items of escape data.
That's basically one of the great things and beauty of it.
That's really cool.
And at the heart of it, you've got this CSS method that I can give sort of complex hierarchical CSS expressions
to get a hold of the pieces I need, right?
Yeah.
And on the extraction side, we also provide some convenient methods for extracting the data using well-known selectors
like CSS selectors or even XPaths.
Yeah.
This is like the most universal way to address regions of pages.
So you can do anything with it.
And with the requests to follow, you can generate further requests to make what you would say ASHA calls
in order to retrieve extra data from the web pages.
And here is something to note.
If you want to use this low level, you need to view in your browser what requests the website is doing
and replicate those in Scrappy.
Oh, interesting.
So suppose I want to go and I want to scrape like a single page app, spa type app that's written in AngularJS.
Right?
If I just go hit that with a direct request, I'm going to get curly this, curly that, meaningless, no data, right?
Yeah, exactly.
Exactly.
This episode is brought to you by Hired.
Hired is a two-sided, curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front, and you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers within the first week, and there are no obligations ever.
Sounds awesome, doesn't it?
Well, did I mention the signing bonus?
Everyone who accepts a job from Hired gets a $1,000 signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python To Me, and Hired will double the signing bonus to $2,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python To Me and answer the call.
Remember that Scrappy was built in a different world in 2007.
There was a lot of static.
There was not so much Ajax, not so much JavaScript.
And now with this crazy world moving to more like apps running in websites rather than website websites, Scrappy still is able to do it because Scrappy is, to some extent, a very low level.
Whatever you can do in a browser, you can do in Scrappy because it works at the HTTP response request level.
You sometimes feel that you need something more digestible so that you have the data readily available, the data that is delivered to Scrappy.
Based on this need, we're working on extending Scrappy JavaScript support.
Being the hardcore reusable component funds that we are, we ended up creating a separate component called Splash, which is sort of a mini browser that runs with an HTTP API.
And it interacts really well with Scrappy, which is one of the many libraries that integrates well with Scrappy, so that you can actually have rendered data, JavaScript rendered data available in your callbacks for it to use, as well as executing actions on the website.
That's really cool.
I didn't know it did that.
So that's really excellent.
Yeah, it's not one of the things that are most prominently shown when you came across Scrappy.
Yeah, of course.
But if you've got to go after a website that's sort of one of these front-end JavaScript data binding type frameworks, you have to have those things.
That's really cool.
So another thing that's in your sample that I think is worth bringing up just really quickly, although it's not specific to what you guys are doing, is you're using the yield keyword and your parse methods.
And the bit that you do supports sort of these generator methods.
Yeah.
And these sort of progressive get-as-much-as-you-like type of methods.
So do you want to maybe just talk really quickly about generator methods?
Because I don't think we've talked about it on the show very often, if at all.
Yeah, absolutely.
So this spider callback that I was talking about actually can return a generator or an iterator in its most general form.
So what Scrappy does internally, it calls this callback and starts iterating the output of it.
So it can potentially return an infinite generator.
And Scrappy sometimes is used that way.
You start in a page and start monitoring the page and keep returning data and your requests to follow as they appear.
Or you generate just incremental numbers or whatever of pages to check.
And yeah, Scrappy uses memory efficiently in order not to consume the whole generator at once.
It consumes its incisable, manageable parts.
And it has a bunch of flow control directives in place to make sure that no place in the framework consumes too much and overflows memory.
This has the result that in the spider code, you can use nine things like GIL,
where you just send the data out into Scrappy framework side.
And you'll be sure that it's going to get processed and you don't have to check yourself that if you're sending too much data or too little or whatever.
So yeah, that's how you can make benefits of how Scrappy makes benefits.
Yeah.
So internally, it uses iterators everywhere.
And you can just layer on your own iterators, right?
Because if it would build like lists and, you know, fill them up, that would kind of be useless, right?
Exactly.
It's iterator and generator friendly by default.
And you can take that advantage.
Yeah, that's really awesome.
If I want to go to a website, you know, maybe let's just take somewhere like the New York Times, say.
So the New York Times, they're a well-known newspaper.
Their articles are highly valued.
But there's also usage restrictions.
They have their so-called paywall about trying to make sure you have an account and stuff.
Is it legal for me to go and turn Scrappy loose on the New York Times?
Or what's the story sort of around like when I can and can't use the web scraping?
We like to see scraping as a tool.
And as with many other tools, you can use it for with legal purposes in mind and illegal purposes in mind.
Even tools like Bitstorrent, which is a de facto example, can be used for completely authentic and genuine stuff, legal stuff.
I'm not saying that.
So they use what you're doing with the tool is ultimately what makes it illegal or not.
In the case of the New York Times, you should probably obey whatever rules they have to access the content.
I hope that sometimes they will realize that they are doing it wrong.
You can't see, at least I don't see scraping as a way to get data, to steal data that isn't supposed to be taken.
There's a lot of projects and stuff out there that uses scraping to just gather the data that is already available there in order to process it.
Right.
Like a really common example would be Google.
Exactly.
I don't know that they use Scrappy, but obviously they do that.
Conceptually, they do that, right?
Exactly.
Google is the largest scraper in the world.
And they get the data and add value to it by showing them their search results.
Similar thing applies everywhere for us and how we tackle projects.
We generally go with public information only when we work on scraping projects.
We don't want to deal with all the legal stuff like this.
And yeah, we always recommend customers to get proper assistance and possible consent from the websites to get the data.
Because many cases, believe it or not, their websites don't care if you take the data from them.
But they just don't want to go through the table of packaging the data and sending it to you or putting it from you.
Yeah, right.
Or maybe they would like to, but they're technically incapable.
Exactly.
Not everybody who has a website is a programmer.
Yeah.
I've heard so many times saying to website owners saying, okay, if you can take the data and you don't cause me any problems, then go for it.
And you wouldn't believe how common that sentiment is.
Yeah, yeah.
That's really cool.
Let's talk about large-scale web crawling.
I mentioned Google.
That's kind of large-scale.
You had your experience with thousands of crawlers.
What do you need to worry about when you're running stuff at that scale rather than I have my app that goes to one page and just get some information?
Right.
Scalping can kind of scale in two directions, I would say.
One is the code direction and another is the infrastructure and volumes direction.
Large-scale at the code side could be having to maintain a couple thousand spiders in your project.
Let's call it more vertical scaling, if you will.
Whereas scaling in the horizontal or infrastructure side would be having a single code, perhaps more automated or based on sophisticated extraction, that needs to grow a lot of web pages, like hundreds of millions of web pages.
Okay.
And that's more like what you're talking about with the machine learning.
Maybe you would do Scrapey plus scikit-learn and a single code base to just go understand the web versus I know that these are the 27 retailers' websites and I want to give you the price of all of them.
So I'll write specific code to get the price of these common objects.
Something like this, right?
Yeah, exactly.
And you can only scale so much, vertically scale so much with numbers of spiders because the cost starts increasing quite a lot to keep these spiders running and well-maintained.
So because spiders break, you need to monitor them, react when they break, and the size of the team that you need to have to maintain them goes up really quick.
You get a little nice happy message from Target saying, we've just redesigned Target.com.
And you're like, oh, no, there it goes, right?
Yeah.
Don't get me started with Black Friday and holiday seasons.
Challenges vary depending on which case we're talking.
The code scalability is somehow minimized or addresses as much as possible by scrappy common conventions.
It's as much as you can do.
I mean, in the end, you have to write the XPaths or CSS selectors anyway at some point.
But aside from that, anything else that can be automated, infrastructure or review all sides, we try to automate it.
The other type of scalability problems are related with crawling a huge number of pages.
There involves not only the massive amount of data that you need to go through and to digest, but things like revisiting policies for when you have to keep track of a huge number of pages in a very large website or group of websites.
And you only want to revisit them depending on how often they get updated.
So there's a few common algorithms used in this case.
But the big challenge here is keeping this big queue of URLs that you need to keep control of and prioritize.
Because the crawler just kind of takes URLs from a queue.
Crawler just will ask a queue, okay, what's the next URL you want me to fetch?
And it will take that URL, fetch it, return the process results.
But keeping this queue is the challenging thing when doing it at scale.
Yeah, yeah, of course.
Because you want to, you know, cache, sort of conceptually cache as much of that as possible and not hit it if it's not going to have changed.
Is that a place where you could plug in, like, machine learning and have it watch and sort of tell it, like, this time I learned something new, this time I didn't.
And it could maybe be smart about this?
Yeah, yeah, exactly.
As I was saying, there's a few common algorithms used to revisit simply based on frequency.
For example, frequency of updates.
Like if you visit a page two times during a certain amount of period and the page is the same.
Or actually the extracted data is the same.
Exactly.
That's what matters, right?
Just to, yeah, to take out overhead changes.
Then you perhaps double the time that you're going to check that page again.
So if you revisit in a day, it didn't change.
Then you're going to visit again at least in two days from now.
And if the page changes, then for that page, you reduce to the half of the time that you waited.
So you're going to revisit in a half day.
And let the wait times adjust automatically.
That works as a basic algorithm.
It works really well.
And Scrappy has its own internal scheduler, which serves as this in-memory queue for requests.
It can only grow so much because Scrappy all runs in a process, in an operating system process.
And there's memory limitations when running a single process.
So when you need to scale to very large number of web pages, you need to use something external.
And on this side of the equation is that we're working on for just over a year now in a new project called Frontera,
which is an extension to Scrappy to deal with large crowds.
And it essentially manages what is called the crawl frontier.
I should have mentioned before, but this queue of requests to follow is called the crawl frontier in Scraping and web crawling terms.
Yeah, very cool.
You guys also built like a web crawling as a service or web crawling infrastructure as a service, if you will, right?
Tell me about that.
Yeah, so one of the things that are common to many Scraping, if not all Scraping projects, are the infrastructures required by it.
As I was saying, writing the CSS selector expat is something that you may need to do separately for each website.
But all the rest, like running the spider, getting the data, reviewing the data with your colleagues or customer, iterating over it, is pretty much the same.
And it's surprisingly what ends up taking more time than writing the CSS selectors or the expats itself.
Because when you're dealing with data, sometimes there are different expectations of how the customer needs the data and how you produce it from your spider.
So being able to have those in sync with an efficient tool is of crucial importance.
So we realized this around 2010 that there was a business opportunity to launch a tool for taking the next step after Scrappy.
Because Scrappy kind of solves the problems at the developer level.
You can run Scrappy Spider with the Scrappy crawl command.
It all works the same in any machine, in any platform.
But what after that?
What if you need to collaborate with teams?
Then it starts getting a bit complicated.
We started Scraping Hub to deal with that, with running Scrappy Spiders in the cloud in the most friendly way possible.
So that developers can benefit from it.
Yeah, that's cool.
And that's just at scrapinghub.com, right?
Yeah, exactly.
Yeah.
So people can check it out there.
Maybe tell us, like, what is the main use case?
Like, why do people come and set up a system to run on your platform?
The nice thing about Scraping Hub is that you can run any Scrappy Spider that runs in your machine already will run on Scraping Hub cloud.
So that's the premise of the service.
We don't require you to make any changes to your already working spiders.
You can just run a command, Scraping Hub, deploy, and you have it already deployed in our cloud.
And you can run it using the web analytics panel from there.
Think of it similar to Heroku here.
Not sure if you're familiar with it.
But Heroku is the same for websites.
You have a website running locally.
And yes, you need to configure some manifest file for sure to indicate a few things.
But that's all you need to do.
And then with Heroku.deploy, you have the website running.
It doesn't matter where you have the URL.
And anyone can access it.
We wanted to build the same for spiders.
There wasn't anything like it.
And still, there isn't.
And we realized that we had kind of this, the best framework for writing with spiders.
And kind of the next obvious thing to do was to give it the friendliest way possible to run this and collaborate with your team.
You can run and you can see the stuff, the data that is being scraped with the images or all those things like nicely rendered.
And you can add inline comments to the data to check and mention colleagues to check if it's okay.
The other big piece of infrastructure is that you need to, it's very hard to have this infrastructure when you're small.
So it doesn't make sense to build this if you're just crawling a few sites.
Although big companies that do a lot of web crawling like Google have their own sophisticated crawling infrastructures already in place.
And having a sophisticated crawling infrastructure in place is a pretty daunting task for a small startup or for a small company.
So we wanted to make that accessible for small companies when we started escaping how all this or as much as this nice infrastructure perks that one has when you have a recently large crawling infrastructure.
Make it available to everyone.
That's really an interesting mission.
I mean, if I was going to do a startup and a key component of that was to go out and just gather all this data through web scraping, you know, you could set up your own infrastructure on AWS or DigitalOcean or wherever.
Right.
But that's not your job.
Why do you want to do that?
Right.
Just drop it over there and let you guys deal with it.
Continuous delivery isn't just a buzzword.
It's a shift in productivity that will help your whole team become more efficient.
With SnapCI's continuous delivery tool, you can test, debug, and deploy your code quickly and reliably.
Get your product in the hands of your users faster and deploy from just about anywhere at any time.
And did you know that ThoughtWorks literally wrote the book on continuous integration and continuous delivery?
Connect Snap to your GitHub repo and they'll build and run your first pipeline automagically.
Thanks SnapCI for sponsoring this episode by trying them for free at snap.ci slash talkpython.
That's what we try to convey.
Like, we are the Heroku of, we're trying to become the Heroku of web scraping.
You can always build an AWS server or DigitalOcean server and deploy everything there.
And it will work because everything is based on open source tools and we have remained firmly connected.
against any type of vendor lock-in.
We release as much as we can on open source.
And I'm not understating this in any way.
The things that we haven't yet open source, if we haven't cleaned them enough to send them out there.
And it will cause more harm than good being out there.
But eventually we see ourselves like open source and everything and charging for infrastructure, essentially, to run those things.
We don't want to charge for code licenses.
Right.
Do you see it as somewhat analogous to OpenStack?
Yes, absolutely.
From a business model.
Yeah, absolutely.
Because the infrastructure is something that you can never expect to open source, right?
So there's, it's not like a major flaw that we could have at some point.
And so, yeah, it's very similar in that regard to OpenStack.
There's also two types of customers, right?
as sometimes I say, like developers with no money, but very eager to learn and do stuff.
And companies with big pockets and no time and they want things like working tomorrow.
We're trying to fulfill both targets, right?
We have a business division in Scape and have that where you can get the spider written and everything
and you don't need to do anything, just get the data.
But internally, this uses all of the rest of our platform that we share with developers
in the world.
And we both work on the platform.
So if you're a developer, you can use the platform.
And if you're a business, you can hire developers to using the same platform, get the job done
for you.
And I believe that trying to fulfill both audiences is key for business built around open source
to succeed.
Well, I guess you could extend that to any business.
But it has been one of our best decisions.
And I've always been a fan of building developer tools.
Coming from a developer background, and I'm still a programmer first and foremost.
I love tools that are well done that allow you to enjoy working and having fun while you
work.
So I love building these things.
I always like when I wanted to work on something, I first try to build tools to make that something
more efficient before actually going to work.
Yeah, that's cool.
And now you just get to enable other people to build their thing, right?
And you get to just keep working on the tools.
Yeah.
So I want to come back to this idea of open source and business.
These are very interesting mixes to me.
Real quickly, what's the future of web scraping like?
From where we are now, what do you see coming up in the next five or 10 years that's going
to be different?
Well, the web is going to be there still, that's for sure.
Technologies will change quite a bit in five years if you look back at what happened in
the last five years.
And I think the world is a lot less proprietary now in terms of internet technologies.
Perhaps the last big one was the fact that Flash lost to HTML5.
It's kind of the last example of a big proprietary versus open technology.
Yeah, that's a big technical wall coming crashing down that will let you into that area now,
right?
Yeah.
So of course, we benefit from the fact that everything is in HTML.
It's going to be more in HTML out there.
And it will continue to be.
But the point is that technologies may change a bit, but the information that is available
out there will need to be retrieved and used by companies.
So scraping in general, I don't think that it will change much the concept.
The earlier concept of screen scraping, of extracting data from screens rather than from web pages,
still remains to this day.
And if anything, it will change a bit in terms of how you extract the data.
And it's going to involve a lot more JavaScript processing and kind of tool automation for reproducing
actions rather than following links to follow the pattern of how web applications are transforming.
But I don't expect a lot of that to change aside from that, really.
But there's going to be a lot of sophisticated technologies that will keep increasing on the
side of keeping web crawlers away, detecting web crawlers and banning them for sure.
There's a bit of an arms race there, right?
Yeah, yeah, exactly.
It's a...
User agent equals MSIE 10.
Yeah.
Things like this, yes?
That summarizes well.
But yeah, the fact that the companies are going to be more protective of their data, or some
of them, the ones that consider it a core business value, will mean that the scraping technologies
will need to evolve and become more sophisticated as well to follow it.
So there's going to be a large, very expensive, private market where you will be able to find,
I don't know, mechanisms to still get the data out of web pages with an even bigger infrastructure.
That's not like the focus of what we're trying to achieve, right?
Right, of course.
So two other things that are sort of not knowing anything about this come to mind for me is,
one, you talked about the JavaScript front-end stuff, the fact that you guys support grabbing
sort of AngularJS style apps.
I think there's more of those, right?
So that'll be interesting.
But what about HTTP2?
Will that have any effect on you guys, or better scalability, or no effect?
What do you think?
No, I don't see HTTP...
I mean, it won't change really much.
It's going to be part of...
The framework will be adapted to take HTTP2 enhancement in hand, but the discipline of the scraping data,
I don't see it will change much after that.
Yeah.
Web sockets may require, if you think of it, a more...
It's a different approach to it.
Yeah, when the data starts coming out of web sockets.
Yeah.
I guess that we haven't done pretty much any web sockets scraping recently, or at all.
And I really haven't put a lot of thought to it.
It hasn't crossed my mind a lot later.
Sure.
So let's talk a little bit about, while we have a few minutes left, let's talk about business, open source, making a living on open source.
There's some really powerful examples of companies doing this and people doing it.
But there's also a lot of people who dream of it, but don't see a path forward.
Right?
Notable examples of people making it work for companies.
Continuum, the Anaconda guys, the Red Hat OpenStack, MongoDB.
Those are all really companies that have somehow made open source work.
Somehow made it work.
Somehow.
But there's got to be a ton of failed attempts, unfortunately.
So maybe tell me, how is this going for you guys?
What's it like to run sort of a distributed company that builds an open source product, but still somehow makes it a business?
We started by doing a lot of professional, and we still do a lot of professional service work consulting using our own tools.
So you need to keep this mind, this audience of companies and businesses that could benefit from your open source project if you want to make a living out of it.
In our case, it wasn't too difficult, right?
Because there's a natural need from data.
Data is king, and many companies are after data.
And the open source tool that we developed and we maintain is related to extracting data.
So we started escaping here with no standard funding and still don't have any by providing solutions to these companies, first and foremost.
And then we were able to evolve the open source products as the needs of our customers require, improving it along the way when we found the opportunity.
And even up to this point, the modus operandi is very similar.
So try to find, I would say, try to find where your paying customers will be, like companies that will benefit from your open source project.
And try to build, like try to build a company that proposes, provides these offerings.
In our case, we did it by providing development expertise to write web crawlers.
But it's very similar how we did it with how continuous that's it, for example.
And I'm a big fan of them.
And it's a really nice model to follow.
They do a lot of consulting, but they keep this Anaconda platform and everything that makes their jobs easier.
And at the same time, allows them to spend working on open source a lot.
And I always wanted to be able to just live in the open source world and keep coding on Scrappy.
Unfortunately, I'm not able to code much on Scrappy these days.
But I plan to return to it once the company runs in autopilot.
And I'm able to retire to get back to Scrappy and size projects.
But yeah, if you're just trying to connect the dots to where companies will make use of the open source project that you're working on.
Like if you're working on something like Bootstrap, find a consulting company that builds websites quickly, prototype websites quickly, those type of things.
So let me think through if I were trying to plan this out for Scrappy, how it might go.
So if I were, you know, you guys five or eight years ago, whenever, before you started Scraping Hub, I'm thinking, okay, well, I've got this really successful web scraping open source project.
And people are using it.
The company is using it.
They're really just, they're using it as a tool.
But the thing they actually want is they want lots of data off web pages fast.
And so then how do you build a business?
I think it makes perfect sense to say, well, let's build like this infrastructure where you can take the thing you're already doing and just push a button, drop it onto it and deliver the data fast in a reliable way without all the other stuff, right?
Without adding anything to it.
Yeah, yeah, yeah.
Is that kind of the thinking you guys went through?
That's a perfect example.
And in fact, we didn't focus early on just pushing a button and getting the data automatically.
We focused more on the provides engineer hours and consulting and training for our tools.
But we are very much focused on data marketplaces and automatic APS to do extraction right now.
But the model is just what you just described is also perfectly possible.
I mean, it's another way to go about doing that.
And it's even better if you find a way to productize your open source project in a way that companies can be able to benefit from it without having to go through all the installation and configuration and customization phase.
So if you find a way to productize your open source project and provide it in a hosted manner, it's another very common example of a few successful ones.
Like GetSentry, for example, this tool for monitoring websites.
They provide a nice hosted solution of the open source tool and they're doing awesome.
Yeah, that's another model that works really well.
It's in the end a matter of finding where your tool produces value to business and try to sort of connect the dots or try to offer it so that when you're working for your customer, you're implicitly forced to work in your open source project and remain connected to it and growing it.
You need to find a way to put your open source project in your work agenda.
Right.
So if you do consulting, maybe you make sure that your contracts include clauses that if I'm helping you with consulting using my open source project and there's a natural enhancement that I could add to the project, but that would be kind of driven by your need.
Make that possible for me to put that in my open source project without any conflict.
Something like that, right?
Exactly.
In our cases, we include a clause like that.
Sometimes we even get Scrappy enhancements sponsored by our customers, which is great.
You can get that win-win situation.
You need to be a bit creative, of course, and be patient as well.
For a long time, at the early stages of Scrappy, I was working on it in my extra time and I wasn't really sure where the project was going or if it was going to be successful at all.
But I just wanted to build something.
That was my main motivation back then.
Create something of value to developers because I was a developer full-time back then and something that made my show a little more fun.
And that's what I did.
And then it was later than I realized I had a nice thing going on, a nice open source project that the community has gathered around.
First, it was just a couple of guys and I tried to help them and answer a few questions here and there.
And yeah, there was this community that encouraged me to quit my show and focus solely on Scrappy.
Was that a pretty happy day?
Yeah.
At the time, it was a bit crazy, like leaving my show and then just starting this.
But to be honest, I already had a few customers that were going to become immediate scripting, have customers.
So it was enough to sustain a small business because we kind of had the market proven before I started Scrappy.
I know you can do even a lot more risky moves, but I constantly feel proud about the things that Scrappy has achieved.
And a lot of things that are achieved lately are not thanks to me.
Like I'm not super involved day to day in the project itself.
But it's like when you see your kid, right?
That just graduated from college and is doing great things out there.
It really makes me very proud.
And just last month, the first Scrappy book came live.
And that was a really happy thing for me when I realized.
I'm sure you're really proud of it.
That's great.
Congratulations.
So the companies I named earlier, possibly with the exception of Continuum, were really large companies.
But you're not a super large company, right?
How many people work with you?
At the moment, we are 130 people working fully distributed around the world, which to me is pretty big.
But of course, not comfortable.
Okay, that's bigger than I realized.
That's awesome.
Yeah, cool.
So yeah, we were kind of growing and doubling in size every year, more or less.
We never kind of set a goal of like, let's double in size or let's grow to this size.
It kind of just naturally happened.
Like customers were requesting more work and we keep adding people to the team as there was more work.
And now we have a large part of the team working on the platform that already drives a lot of demand.
And running a remote company comes with its challenges, right?
I mean, you have a lot of times on issues.
Coordination between teams, like communication is key.
Self-management is very important.
But in exchange, you have a global pool of talent available to you.
And that's been one of the key, if not possibly the most important thing to be able to grow scraping up to the size that we've grown it so far.
Like we've been focusing really hard on hiding the best talent out there.
It took us a while, but I'm really proud of the team that we have assembled.
And I'm sure that the best is still to come.
I've always kind of worked remotely since I started working professionally in 2000 because I was sort of a sysadmin at the beginning.
So, yeah, I managed the servers from home.
Then I worked for this company in the UK that built this aggregator.
And I was also remote there.
And it kind of felt natural to continue working this way for me.
And also, the things that I learned while managing the scrapping community, I tried to apply them as much as possible to manage the scraping hub as well.
Like the whole culture of not asking for, it's better to ask for forgiveness and permission, those type of things.
I really applied to the scraping hub.
Sometimes I try to see it as a really big open source project with some commercial interest that we're trying to manage.
Yeah, you must be super proud of what you built.
That's awesome.
And I think people will really enjoy hearing this sort of success story from the beginning until now.
That's great.
So, we just have like a couple minutes for final questions.
Questions I always see at the end of the show.
If you're going to write some Python code, what editor do you open?
Well, I'm a BIM guy.
What can I say?
All right.
Awesome.
That may be the most common answer.
I think it probably is.
I'm quite fond of Sublime.
Yeah.
Because I'm not writing much code these days.
I've tried Sublime a couple of times.
And it's the first one that made me consider leaving.
Leaving.
But.
Yeah.
It hasn't pulled you over to its side yet.
No.
Not yet.
All right.
And from all the packages on PyPI, there's 70 something thousand these days.
There's so many that are awesome that maybe people don't know about.
Like, what would you recommend?
Like, obviously, pip install Scrappy.
And then anything else?
There's a whole bunch of interesting stuff there.
It's hard to name, to pick one.
I'll just try to think one that is not part of Scrappy ecosystem.
Do definitely give a try to Sentry if you're running a website.
It's really cool stuff to monitor websites.
Okay.
Yeah.
Sentry's nice.
Yeah.
That's, I guess I will go with that one.
Go with Sentry.
Awesome.
Okay.
Before we let you go, any final calls to action?
Things people should go try?
Yeah.
Definitely.
Come try Scraping Hub and you won't forget if you have any Scraping needs at any level.
Like, we are building the most awesome tools to make your shop easier.
So, yeah, I'm always happy to get in calls with people doing things right with Scraping.
And we'd like to learn more about what your needs are and how we can get it easier.
Awesome.
So, everyone check it out.
Pablo, it's been really fun to talk about web scraping.
I've learned a ton from it.
Thank you.
Likewise.
It's a very interesting job.
Yeah.
Thanks for being on the show.
Thank you.
Bye-bye.
Thanks.
Bye.
This has been another episode of Talk Python To Me.
Today's guest was Pablo Hoffman.
And this episode has been sponsored by Hired and SnapCI.
Thank you guys for supporting the show.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python To Me to get five or more offers with salary and equity
presented right up front and a special listener signing bonus of $2,000.
SnapCI is modern, continuous integration, and delivery.
Build, test, and deploy your code directly from GitHub, all in your browser with debugging,
Docker, and parallelism included.
Try them for free at snap.ci slash Talk Python.
It's the final few days for my video course Kickstarter.
The campaign is open until March 18th, and you'll find all the details at talkpython.fm slash
course.
Hurry on over there and sign up before it closes.
You can find the links from today's show at talkpython.fm/episode slash show slash 50.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right near the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song on talkpython.fm.
This is your host, Michael Kennedy.
Thank you so much for listening.
Smix takes us out of here.
Thank you.
We'll be right back.
you
Bye.