3
votes

We have a web app with pages that show users' recent tweets. The REST API only allows 180 requests per 15 minutes. So even if we cache tweets for a few minutes, we'll exceed the rate limit once we have a couple hundred users.

The project owner does not want users to have to provide their own API tokens, and the Twitter Embed widget doesn't match our UX requirements. So I'm looking for a solution.

The best I've come up with so far is:

  1. Standup a second web app that consumes the Streaming API and saves the collected tweets to a database that the main app can read from (Ugh!)
  2. Get a higher rate limit for the REST api (no idea if this is realistic)
  3. Create lots of Twitter accounts and use the individual tokens (Yuck!)
  4. Make requests to the Streaming API for past tweets (doesn't seem possible)

Hoping there's a better way.

1

1 Answers

0
votes

the Twitter Embed widget doesn't match our UX requirements

If this is going to be a publicly facing site, remember that Twitter wants you to comply with their brand guidelines.

So, using the official widget is the easiest way to do this.

The project owner does not want users to have to provide their own API tokens,

Why not? If you're going to be showing people their own Tweets, presumably you need to know their Twitter name? Asking them to sign in with Twitter will give you their name and get you an OAuth token to use. All the user needs to do is click the "Sign In" button.

Standup a second web app that consumes the Streaming API and saves the collected tweets to a database that the main app can read from (Ugh!)

Why "Ugh"? That's exactly what the streaming API is good for - reading Tweets in real-time from one or multiple users.