Coming from php(mvc background), the only thing i don't like about tornado is that basically you have a Class per request, currently i'm in a process to refactor this so that: www.site.com/controller/action/params/?vars -> would route to -> class controller(requestHandler): def get_action(self, *params, **vars): #do something self.write(response) def post_action2(self, *params, **vars): #.... and so on ....
Im a PHP developer who uses Tornado and I recently wrote a PHP micro framework that works like tornado's controllers where rest verbs were the only publicly (uri) accessible methods
Tornado is intriguing, but the main thing I don't like about it is how it reinvents the wheel with a lot of its components. For example: - They created a lot of Web-stuff parsing code themselves, when Werkzeug provides a tested and thorough implementation of a lot of that. (Especially routing, regex-based routing just looks horribly kludgy once you have used werkzeug.routing.) - They created their own template langua…
If you bring in tons of third party code you end up with a mess like Pylons. For people new to a framework, it's a pain to learn that when a problem arises you need to go look up the docs for a separate framework.
That sounds wrong. You need async database access so that while you're waiting for a query to finish, you can still process other requests. Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from b…
From this thread https://groups.google.com/forum/#!topic/python-tornado/mgj18... (posting here because Google Groups sometimes require login): We experimented with different async DB approaches, but settled on synchronous at FriendFeed because generally if our DB queries were backlogging our requests, our backends couldn't scale to the load anyway. Things that were slow enough were abstracted to separate backend serv…
Not sure friendfeed ever got enough users to know scaling issues...
Personally I would go with async DB, or have DB access in its own thread(s) and async communicate with that.
For a multiplayer, realtime, text-based game, like a quiz, should I dive in nodejs or Tornado? I know Python but never played with server-side javascript before.
It all boils down to what you prefer. They're both relatively mature software packages that are being used by tons in production.
Whichever you choose, you may find that http://socket.io/ saves you some time by inventing various wheels you may have needed to reinvent (for use with tornado, see the tornadio project).
Coming from php(mvc background), the only thing i don't like about tornado is that basically you have a Class per request, currently i'm in a process to refactor this so that: www.site.com/controller/action/params/?vars -> would route to -> class controller(requestHandler): def get_action(self, *params, **vars): #do something self.write(response) def post_action2(self, *params, **vars): #.... and so on ....
I don't get it. Your example is what Tornado looks like:: class LoginHandler(RequestHandler): def get(self): self.render('login.html') def post(self): self.set_secure_cookie(self.get_argument('username')) self.redirect('/') Having one class per URL is very common and perhaps it's more than a decade of Python web programming but I like that. Makes for neat code.
The one class per action pattern helps with async calls and callbacks. The handler class has methods for each HTTP method plus the callbacks it needs.
That would get really messy in a controller-with-multiple-actions pattern as the controller classe now has a lot more methods in a single class: all the HTTP methods it handles plus the callbacks for all of them.
Tornado is intriguing, but the main thing I don't like about it is how it reinvents the wheel with a lot of its components. For example: - They created a lot of Web-stuff parsing code themselves, when Werkzeug provides a tested and thorough implementation of a lot of that. (Especially routing, regex-based routing just looks horribly kludgy once you have used werkzeug.routing.) - They created their own template langua…
tornado.database has no real ties to the rest of the system; you can (and I usually do) use SQLAlchemy or another database layer instead. You can also call another template engine if you prefer, but you're sort of stuck with the url routing.
The theory is, you shouldn't need async database access. If your database is a bottleneck, you are screwed, regardless of how your app layer is scaling. The main advantage of async is not blocking if you call an external web API.
That sounds wrong. You need async database access so that while you're waiting for a query to finish, you can still process other requests. Imagine an app that receives an HTTP request every second. One in five of these requests requires making a query that takes 3 seconds to complete. The rest is serviced immediately. You don't want the long request freezing your entire server and preventing the fast requests from b…
The impact of an occasional slow query is mitigated by the fact that you're running multiple processes. You need multiple processes anyway because of the GIL, so just run a few more to make sure you're able to keep the CPU busy. An async DB interface would be nice, but as long as you keep your database performance under control it's not crucial, so it hasn't been written yet.
I'm especially looking forward to trying the new interface to Twisted and the gen module. I was about to write some async interfaces to things that are currently not - these new modules look like they'll be helping me out quite a bit.
For a multiplayer, realtime, text-based game, like a quiz, should I dive in nodejs or Tornado? I know Python but never played with server-side javascript before.
It all boils down to what you prefer. They're both relatively mature software packages that are being used by tons in production. Whichever you choose, you may find that http://socket.io/ saves you some time by inventing various wheels you may have needed to reinvent (for use with tornado, see the tornadio project).
90% made up my mind to use Tornado for several upcoming projects, would love to hear some comments (good or bad) from anyone thats used it or using it.
I too am in the Tornado's camp. I love its simplicity. It has decent documentation. And if there's something you don't understand you just peek at the source. I tend to write my code independent of tornado, so if the need arises I can switch to a different framework.