Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tornado 2.1 released

tornadoweb.org

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Tornado 2.1 released

#31

Post by crad »

bdarnell wrote: post #26
LeafStorm wrote: post #20

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.

I'd be curious as to how many people actually use it. Since it's MySQL specific, it holds little value for anyone not using MySQL ;-)

Re: Tornado 2.1 released

#32

Post by bdarnell »

crad wrote: post #31
bdarnell wrote: post #26

Earlier quoted context omitted.

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.

I'd be curious as to how many people actually use it. Since it's MySQL specific, it holds little value for anyone not using MySQL ;-)

20% of survey respondents reported using it in february: http://dl.dropbox.com/u/19694335/tornado/Tornado%20usage%20s...

Re: Tornado 2.1 released

#33

Post by jamesgeck0 »

rgarcia wrote: post #22
LeafStorm wrote: post #20

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.

Or you end up with something really solid and enjoyable to work with, like Flask. Which is just a combination of Werkzeug and Jinja with some glue and excellent documentation.

Re: Tornado 2.1 released

#34

Post by oxfordus »

ovi256 wrote: post #25
peterbe wrote: post #19

Earlier quoted context omitted.

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.

i dont agree with you, i would rather have a controller with multiple actions, rather then "controller"/requestHandler per action, because in most cases you want the controller to handle all the actions of a page, rather then one action.

Having controller per one action would put overhead on the code lines you write.

Re: Tornado 2.1 released

#35

Post by frio »

rjd wrote: post #2

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 wrote a web service in Tornado around a year ago, pre-1.0. It's a very nice, albeit minimal framework. In terms of comparisons to others:

* it feels easier to scale up than Flask, but that could be my minimal Flask experience showing. Certainly, it is more performant than basic Flask installations and configurations.

* it makes it harder to separate your concerns than, say, Django. I've been working in Django for a long time, and while I have definite issues with the "app"-style packaging (ie. if I add an external forum framework, for instance, I need to munge my "profiles" app to support it), it does feel easier to separate your concerns in Django than in most other frameworks I've used.

* it's fast, and reasonably agnostic - the MySQL DB layer, for instance, can be completely eschewed for something else.

I imagine they've added a lot to it since then, and the service itself isn't something I've looked at for a while (failed startup idea). But from what I used back then, I'd definitely recommend it.

Re: Tornado 2.1 released

#36

Post by wisty »

spokengent wrote: post #23
dchest wrote: post #14

Earlier quoted context omitted.

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.

From Wikipedia: [FriendFeed] had on average one million monthly visitors ... [and] was bought for $15 million in cash, and $32.5 million in Facebook stock.

I figure after the first million users, your embarrassingly parellel app server layer is not your bottleneck, it's getting the database to scale.

Post reply on HN