A Faster / More Scalable Approach to Twitter OAuth Dance in Rails?

Question

I'm running a Rails app on the Heroku Stack (complete with Memcached, DJ Asynchronous workers, MongoDB persistent storage).

Right now we use Twitter Oauth as the only authentication option on our site. (We plan to branch out to FB connect, OpenID, and/or Email/password eventually).

Ruby/Rails apps, as you probably know, don't support concurrency out of the box. On Heroku, you can spin up additional app instances (dynos), which increase your concurrency (concurrency capability = number of dynos), but each one costs $36/month.

In general, this hasn't been a problem, because the average request on the site takes <100 ms.

EXCEPT for Twitter OAuth. The OAuth-related requests to Twitter take, on average, around 3,500 ms.

So basically, when anyone logs in an entire app instance gets held up for 3-4 seconds.

Is there any decent way to mitigate this? Would it be weird to put these actions in asynchronous DJ workers? It could make logging in a little slower, but at least if a bunch of people are logging in at once and/or Twitter is being really slow, these processes do not affect the rest of the app / other web requests?

Any other ideas?

Answer 1

You could push the oAuth into a rack middleware app - then at least only a rack app gets spooled up instead of the whole rails stack. That should make it a little quicker (though it will still take up an instance).

That being said, there is no reason why you can't put authentication into it's own app, especially if it's all in the same domain (so any authentication cookies are still local to the domain). Though you'll have to be really careful of security issues - eg man-in-the-middle attacks etc. Better if somebody's already done the work/bugfixing for you :)

You can even have an authentication app on an independent app domain if you use rubyCAS: http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html