
Tornado 2.1 released - dtwwtd
http://www.tornadoweb.org/documentation/releases/v2.1.0.html
======
LeafStorm
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 language when they could have used Jinja.
(In fact, tornado.template is basically a half-as-powerful copy of Jinja.)

\- They created their own database access layer when they could have used
SQLAlchemy instead.

Sometimes I think people take the concept of "minimal dependencies" way too
far.

~~~
bdarnell
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.

~~~
crad
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 ;-)

~~~
bdarnell
20% of survey respondents reported using it in february:
[http://dl.dropbox.com/u/19694335/tornado/Tornado%20usage%20s...](http://dl.dropbox.com/u/19694335/tornado/Tornado%20usage%20survey%20results.pdf)

------
rjd
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.

~~~
zeemonkee
I've noticed that Tornado comes with its own MySQL wrapper, however I'm
concerned it might have blocking issues.

Does anyone have experience with using this ?

Also, what do people use for form validation with Tornado ?

~~~
wisty
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.

~~~
wulczer
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 being serviced.

~~~
dchest
From this thread [https://groups.google.com/forum/#!topic/python-
tornado/mgj18...](https://groups.google.com/forum/#!topic/python-
tornado/mgj18IzasQg) (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 services which we fetched asynchronously via the async HTTP 
      module. 
    
      I may open source the async MySQL client I wrote, but I am still 
      skeptical of the long term value given the code complexity it 
      introduces. 
    
      Bret

~~~
wulczer
Erm, so if things are fast it doesn't matter and if things are slow you should
write a whole new service, put a HTTP interface into it and use that? Not sure
I buy that :)

Disclaimer: I wrote an async DB module for Twisted/PostgreSQL and it did not
turn out to be all that complex.

~~~
wisty
There's async libraries here: <https://github.com/facebook/tornado/wiki/Links>
\- You can get just about any db _except_ MySQL. There's ones for Couch,
Mongo, HBase, a bunch of other No-SQLs and Psycopg (PostGres).

Also, Tornado is now introducing some kind of interface to Twisted's event
loop, which _does_ have everything ported.

Bret just doesn't seem to want async My-SQL in the main code base.

------
oxfordus
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 ....

~~~
peterbe
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.

~~~
ovi256
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.

~~~
oxfordus
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.

------
slig
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.

~~~
mtogo
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).

~~~
slig
Thank you! Didn't know about tornadio.

------
dtwwtd
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.

