
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>A: respond quickly by putting the external API call to backgroundjob, and check the response via ajax periodically (could use commet or websocket alternatively).</div></blockquote><div><br></div><div>+1</div><br><blockquote type="cite">

<div>B: separate this long running request to different component (eg: node.js on heroku or other PAAS) and call this via cross domain ajax call.</div></blockquote><div><br></div><div>You can't sign up for a node.js account on Heroku any more :(</div><br><blockquote type="cite"><div>C: Don't use Heroku. Heroku is not meant for that kind of purpose.</div>

</blockquote><br></div><div>That's an option. But you're going to have a similar problem wherever you take an app like this. If you're sticking with a ruby stack, I'd opt for option A). If you're keeping it on Heroku, then you'd need to pay for a worker to pick-up the jobs. While I don't know the exact figures, I suspect that if you tried to fix it by increasing the number of dynos to hide the latency from concurrent users you'd need to scale dynos up quicker than you'd have to scale workers.</div><div><br></div><div>It's still early days, but I think this library is looking promising for doing job management in a simple and sensible fashion:</div><div><a href="https://github.com/ryandotsmith/Queue-Classic">https://github.com/ryandotsmith/Queue-Classic</a></div><div><br></div><div>Glen</div><div><br></div><div><br></div><br></body></html>