Hacker News new | past | comments | ask | show | jobs | submit login

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've used both Django and Tornado and I vastly prefer Tornado.

Some personal experiences: With Django, I specifically don't like ORM and it's template language. Also, I thought the admin interface would reduce the need to write input UIs, but at the end of the day, it's not that suitable for end-user when you have several end-user roles with different access right patterns.

If you (read: I) are going to replace Django's template language and leave out ORM and admin interface out of Django, Django doesn't really shine anymore and simpler frameworks like Tornado provide cleaner base for your development.


Hm, you could take a look at pyramid, if you dont like djangos orm or tempalting it might just be right for you.


When speed isn't important and you know you want to use a SQL database; then use Django. For everything else, use Tornado. :)


when he says Django he really means Flask :-p


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 ?


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


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


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.


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.


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.


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 am curious about what kind of libraries are compatible with Tornado as well. Is there a list that someone maintains? I am specifically interested in things that can bring a bit of the goodies that django provides.


I've recently been blogging about my tornado-utils library which, for example, brings a email sending library similar to Djangos http://www.peterbe.com/oc-Tornado


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.


I'm a convert from Twisted.

It is simple enough, the code is clear and small enough to dive into if you have any problems, and it works just great.


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.


Easy to get started, easy to deploy, pythonic/magic-free code, responsive maintainer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: