rainbows for 3rd party api

[Eric Wong]

Giovanni Lion <giovanni.lion at gmail.com> wrote:
> On Fri, Nov 6, 2009 at 12:06 AM, Eric Wong <normalperson at yhbt.net> wrote:
> > Giovanni Lion <giovanni.lion at gmail.com> wrote:
> >> 4) I write the response to memcached
> >> 5) I call the rails app who now fetches from cache the friend list
> >> 6) The rails app renders the partial and everybody is happy
> >>
> >> Do you think this is a good flow? Should I create a specific method instead?
> >
> > Depends on the rest of your app, I guess.  Is your Rails app
> > reentrant?  If so, definitely go for it.  If you're dealing
> > with DB connections in there, compatibility will probably be
> > better with the ThreadPool or ThreadSpawn models unless somebody
> > writes Revactor-enabled DB libraries.
> 
> Well, I do have a db in there but it's just one users table, which i
> really need only to pair the facebook id to the oauth tokens to make
> the api calls. Unfortunately it's a 3-legged oauth so i'm kinda stuck
> with having my own db. I'm testing now something like this:
> 
> map("/3rd_party/friends") do
>   use Rack::Facebook #checking the fb signature
>   run lambda { |env|
>     request = Rack::Request.new(env)
>     return Rack::Response.new(["Invalid Facebook signature"],
> 400).finish unless request.POST['fb_sig']
>     user = User.find_by_fb_id(request.POST['fb_sig_user']) #db query
>     ...
>     oauth_stuff_i_am_still_working_on
>     ....
>   }
> end
> 
> Will rails connection pool mess things up if used in an actor? Right
> now I'm really much more worried about the app being blocked in the
> http call as the third party is acting wonky lately. Db load is not a
> worry for now.
> 
> Let me know your thoughts while I get the oauth - revactor http going.

I don't think there's any need to worry if your DB queries are fast and
predictable in performance.  Let us know how everything goes.  3rd-party
API calls often pose a scalability issue that Rainbows! is designed to
solve.

-- 
Eric Wong