views:

96

answers:

1

I am not a professional web developer, but I like to wrench on websites as a hobby. Recently, I have been playing with developing a Rails app as a project to help me learn the framework. The goal of my toy app is to harvest data from another service through their API and make it available for me to query using a search function.

However, the service I want to pull data from imposes a rate limit on the number of API calls that may be executed per minute. I plan on having my app run a daily update which may generate a burst of API calls that far exceeds the limit provided by the external service. I wish to respect the performance of the external site and so would like to throttle the rate at which my app executes the calls.

I have done a little bit of searching and the overwhelming amount of tutorial material and pre-built libraries I have found cover throttling inbound API calls to a web app and I can find little discussion of controlling the flow of outbound calls.

Being both an amateur web developer and a rails newbie, it is entirely possible that I have been executing the wrong searches in the wrong places. Therefore my questions are:

  • Is there a nice website out there aggregating Rails tutorials that has material related to throttling outbound API requests?

  • Are there any ruby gems or other libraries that would help me throttle the requests?

I have some ideas of how I might go about writing a throttling system using a queue-based worker like DelayedJob or Resque to manage the API calls, but I would rather spend my weekends building the rest of the site if there is a good pre-built solution out there already.

+1  A: 

The reason nobody talk about outbound throttling is that it's usually pretty trivial, since you control it. Controlling bandwidth can be a bit harder, but controlling number of request ?

ri Kernel#sleep

So, if you're allowed 10 api calls per min you just sleep(6) after each call

Aye, that seems like a reasonable solution- however I do have some issues with it. 1) it would take some fine tuning to get the sleep time optimized and 2) it looks like worker thread would be completely stalled during the duration of the sleep. I would prefer a solution that would cause the worker to defer execution of API calls and process other tasks if the call limit is being exceeded instead of just hanging.
Sharpie
1) What do you mean optimized ? You can't get more efficient than 0% cpu usage !2) Yes that's the point ! If you want other actions to be done, give them to another thread. I don't quite understand why you seem so worried about the perfs of a daily batch job.*) edited the answer about usage
Well, I guess my main concern at this point is that I am considering deploying the app on a platform like Heroku. In this case I would would want to optimize so that each thread works through tasks as efficiently as possible. Since Heroku charges per worker, I would want to use as few worker threads as possible. Maybe I am trying to overly complicate the issue... simple solutions are good solutions.
Sharpie
Since you said you were the only user I was assuming you'd go self hosted.I'm not familiar with heroku but charging by number of green threads doesn't make any sense since you can only have one active at a time. So I suppose their 'workers' are actually distinct ruby processes. There it may be possible to create many threads, only one would be tasked with the throttled calls and others could do anything else. If you can't call Thread.new and assuming there's no worker-startup-fee you could just exit the worker after each call and reschedule the next call on another worker a few secs later.