I’ve been getting a lot of questions about how Gargl differs from to Kimono. The truth is, they are pretty similar! While even I would agree that Kimono is more user friendly than Gargl, overall I think Gargl is better (granted I’m biased) for a number of reasons:
- Gargl is free
- Gargl is open source
- Gargl is “component-tized” – you can write a Gargl recorder for another program like Fiddler or Wireshark, or another browser, and as long as it outputs valid .gtf files, it can be used with a generator (which again is component-tized; you can implement you own generator).
- The APIs it creates and lets you edit can handle more than just GET requests, which is all Kimono supports. Ex: POST
- As long as the generated modules keep track of cookies, you can use Gargl for API requests that require user authentication. Not supported with Kimono.
- Kimono will only scrape at most every hour, and then the API you use gives you stale data. Gargl APIs are as live as you want them to be.
- Kimono operates as a service, even if they “host” your API, you still need to write an API to integrate into their API for APIs! I’m sure they have this available as a client library for some languages, but not all. Gargl will output the module straight in any programming language it supports.
- Kimono operates as a service, so if a site doesn’t want to be scraped by them anymore, it just has to ban Kimono’s IP address. Then your Kimono API would stop working. Gargl modules can be used server or client side. With Gargl, you could run into the same issue using a Gargl module on a server, but if you embed the module directly into a client app so that the module is talking to the website using the client device’s IP address, there’s no way for the site to stop access because requests are coming from each client IP, not from one server IP.
- In my opinion, Kimono is in a dubious area legally. They scrape others’ websites, and expose that data over an API to any paying customer. If a customer does something the site being scraped didn’t want to happen, the site owners could sue Kimono (and very possibly win) for providing this information to its customer, who is doing something the site considers misappropriation of their data or software. See the beginning of my first post on Gargl, where I talk about the legal issues. If Kimono gets sued and shuts down, anyone who used their site to make APIs immediately loses those APIs. With Gargl, it is a decentralized, open source, tool. If someone uses Gargl to make a module and then uses that module to do something against a site that the site did not want to happen, they may get sued, but the tool to generate the module is not directly responsible unlike Kimono, which is actively scraping the website and even being paid by the “malicious” customer.
- Using Kimono, any data you receive has to go through Kimono’s servers in order to get to the API caller. If the data is sensitive, you obviously don’t want it passing through a third party server that you have no control over. Gargl modules connect the API caller straight to the original website, so there’s no third party in the middle you have to trust.
I think the above reasons demonstrate some great benefits of Gargl that are worth sacrificing a bit of usability for. And of course, the usability of Gargl can be improved over time.
That’s my two cents, anyway.
Until next time,
Keep Calm and Gargl On
Hi,
I would like to ask something about support of ajax websites. So I clearly see Gargl superiority in your arguments and I was asking myselft GET ok, POST ok, what if the interesting information in the response appears after a javascript call to something ? This is more and more the case.
Because Gargl is only socket and not a headless browser (for example), it will not get the “entire” response. In theory, this is possible in HTTP because a browser simply communicate with the server with requests. But if there is a solution to this kind of websites, could you explain a bit how to process ?
Example : I want the details of the best price for a flight from new york to san francisco at skyscanner.com
Is that even possible with Gargl ?
I’m not sure I understand your question. Ajax still uses HTTP GETs and POSTs behind the scenes, so Gargl should work fine for that. In fact, in my video showing Gargl, the first request I record (Yahoo autocomplete) is an Ajax request.
Thank you for your answer.
Hi Joe, and thx for your amazing job!
Of course, Gargl is better than Kimono for many reasons, but there is big issue with Gargl.
When you use ajax requests in browser, you can’t do anything if the asked server not allowing cross domain origins. (XMLHttpRequest cannot load ‘DOMAIN-A’. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘DOMAIN-B’ is therefore not allowed access.)
And without this basic rule, Gargl becomes unusable (in a browser context).
I love Gargl, but i cant use it in my projects, so in the meantime, Kimono is the only solution…
Isn’t it?
If you are trying to use generated Gargl Javascript modules in a regular browser context, then yes, you will hit the same origin policy enforced by browser JavaScript. However, Chrome / Firefox Extensions can get around the same origin policy by declaring what sites they will interact with. So if you’re building a browser extension, it should work. If you need to access the site from your website via browser JavaScript, then your only option is to use a Gargl module server side (in Node.JS, for example), and create endpoints in your site that call into the Gargl module. Your client side JavaScript would then simply talk to the “Gargl endpoint” on your website, and use the data it gets back. This is similar to the Kimono model, but many of the pros of Gargl over Kimono still apply, although not all.