Thanks for bringing up the web-app vs chat bot straight away. I did get some questions on these lines during the conference itself. 1) I do not agree that maintaining bots and web apps are the same effort-wise. An IRC can very easily be served of a framework that is event driven in nature -- on the lines of a node.js or eventmachine with barely any additional effort. On the other hand, doing this for a web application would require extensive effort for writing your code the right way and bringing in the right tools like a templating engine. You will build your own framework almost.

2) Since the application is process heavy and take over 45 seconds to serve a request, this would involve extensive tweaking of your forward proxy which in the case of most data centres and clouds will simply respond with a "Service Unavailable" after 30 seconds. Off course you can defer this to a background job and provide the results elsewhere on your application. But like I said, you would be doing things that the user actually does not need.

3) How would you scale up such an operation heavy application if it were a web app. Have 1000 background jobs running for a 1000 users? An event driven approach will pay off for sure. And 1) illustrates why its easier to do this with a bot.

The real disadvantage I came across was to be able to get it to work with a load balancer. I can write about this if there is more interest.