Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from raw Net::HTTP to Faraday #2

Merged
merged 1 commit into from
Mar 29, 2013
Merged

Switch from raw Net::HTTP to Faraday #2

merged 1 commit into from
Mar 29, 2013

Conversation

jasongill
Copy link
Contributor

I've modified the gem to use Faraday, as opposed to raw Net::HTTP. I know this adds a potentially unwanted dependency, but Faraday is very common these days. By default, it uses Net::HTTP so the performance should be identical.

The reason for this is because now if someone wanted to increase the performance of the gem, they could swap out the HTTP backend to be Typhoeus or similar, using something like this:

require 'alexa'
require 'faraday'
require 'typhoeus/adapters/faraday'

Faraday.default_adapter = :typhoeus

client = Alexa::Client.new(access_key_id: "key", secret_access_key: "secret")
url_info = client.url_info(url: "site.com")

All tests are passing for me but I welcome any comments

@morgoth
Copy link
Owner

morgoth commented Mar 29, 2013

Thanks.

I would love to keep gem as simple as possible without any fancy dependencies.

I didn't use Typhoeus before. Is it a lot better compared to requests in separate threads?
In my other gem I tried it this way: https://github.com/morgoth/picasa/blob/master/extra/Thorfile#L39-L46

How would actually look like usage of parallel requests using Typhoeus and Alexa?

@jasongill
Copy link
Contributor Author

Note that my pull request doesn't require or use Typhoeus, it just makes that (one of many) options to use. Typhoeus does have a parallelism module called Hydra that would be interesting to some day explore for bulk Alexa queries but isn't included in this - I simply prefer Typhoeus because it's considerably faster (for me) than Net::HTTP.

By switching from raw Net::HTTP to Faraday, this gem user would have the choice of their favorite HTTP backend using something like my code sample above. However, by default, Faraday uses Net::HTTP so in reality the performance of the gem "before" and "after" without switching to another HTTP backend would be identical.

Many gems that rely on outside HTTP-accessible API's have switched to Faraday for this reason (koala, the facebook gem; instagram; youtube_it; twitter, oauth2, etc).

Note that Faraday also supports, in addition to Net::HTTP (default) and Typhoeus, other HTTP backends that the user can pick from - Excon, Patron, EventMachine. For the normal user, however, adding Faraday to the gem would not change their code or impact their app in any way - this is a drop in update that gives more flexibility to power users

Hope that provides a little clarification :)

@morgoth morgoth merged commit 2369973 into morgoth:master Mar 29, 2013
@morgoth
Copy link
Owner

morgoth commented Mar 29, 2013

Thanks. I think we can try with Faraday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants