Server stress testing and rate limits using the Search REST API


#1

I have an server app (in Google’s cloud) acting as a proxy to the Twitter search REST API for a browser-based JavaScript client. I need to load test the server app but will very quickly run into the rate limit issues. I could simply mock the Twitter API but would prefer as realistic a test as possible. The most obvious solution it to create a number (maybe 10 or 20) extra Twitter accounts for testing only. It this advisable and/or the best or only solution?


#2

You probably shouldn’t build an application in this way – it would seem you’re at risk of creating an open proxy and/or resyndicating Twitter content…


#3

Thanks Taylor

It’s insecure for JavaScript to use the Twitter 1.1 API directly because of oauth issues, so a task specific, very constrained proxy seems like the correct way to go. Can you recommend another way to structure this?

As far as creating an open proxy, the actual search call from the JavaScript uses an opaque, random, limited duration, and browser specific, query id, not the standard Twitter API parameters. There are also a number of other constrains that would make it very difficult to leverage this proxy. The security of public REST APIs that must interact with client-side JavaScript is a large and complicated issue, but suffice to say we are aware of the issues involved.