A good Twitter consultant should start any discussion with a potential client by reviewing the Twitter API rate limits on the features they want. This is really a case of form follows function. Twitter has defined what developers should be doing through their wide range of rate limits, and you better pay attention to them before promising to deliver on a client’s dream app. One rule I start with is: tweets are easy, followers are hard. You can get tons of tweets with the streaming API, which has no rate limits. Getting followers, on the other hand, is something Twitter clearly does not want you to do in bulk.
For example, you can request up to 5,000 followers of a specific account at a time, but you can only get user profiles for these followers at a rate of 100 per API call. This means that there is no way to get the details on all the followers of a major celebrity in anything like real-time.
Another aspect of rate limits that has a big impact on code architecture is deciding which entity is making the API call. If you do everything from a single server with the OAuth keys for the app itself, you only get 350 calls per hour with the REST API. But if you let users login through OAuth, you can use their keys and get 350 calls per hour with each set of keys. Just 100 users give you 35,000 calls per hour. Pretty powerful reason to build OAuth login into a site, right? This is perfectly kosher. You are not really taking anything from the users. Each app they authorize gets 350 calls per hour with a different set of keys based on the same person.
You can also play with rate limits by offloading some of the functionality into the user’s browser. When you make an API call that isn’t using OAuth keys, such as the search API, the rate limit is charged to the IP of the server that connects to Twitter. A way around this limit is to call the search API with Javascript from the web page. In that case, the IP of the user’s browser is absorbing the rate limit. That can scale up to any number of users. We take advantage of this technique in the ThisrThat app we built for a client.
There are lots of other rate limit tricks you can use, but this is enough to make the point that a Twitter consultant needs to make new clients aware of the limits they will be facing before a complete feature list is created.
