shabda
Comments
Reactions

I am so starving: Web app in python frameworks.

By : Shabda Raaj

I have written the same web app in various web frameworks. Get it from Github.

Copied from the Readme.

This is a set of apps which creates the same application in various Python web micro-frameworks.

The app(s) talks to Facebook, and finds out recent people who have posted a public status with the text "so starving".

This idea came from reading Onion.

We have the same app in these frameworks.

Microframeworks:

Full stack frameworks:


If the framework included template engine and caching, that was used directly. Otherwise werkzeug cache and Jinja2 templates were used.

Next step: Write a simple blog engine in these various Frameworks.


Get it from Github.


Related Posts


Can we help you build amazing apps? Contact us today.

Topics : python

Comments

Massimo

Very nice! Would you add a web2py example too? I just made it:

Controller:

import urllib
from gluon.contrib.simplejson import loads

def index():
endpoint='http://graph.facebook.com/search?q="so%20starving&type;=post'
def get_data(): return loads(urllib.urlopen(endpoint).read())['data']
data = cache.ram(endpoint,get_data,30*60)
return dict(data=data)

template:

{{extend 'layout.html'}}

{{ for post in data: }}






{{=post['message']}} : {{=post['from']['name']}}



{{ pass }}


(assuming it is ok using the default layout.html)
It is [running here](http://web2py.com/fmld) and the source code is here [as a zip](http://web2py.com/fmld/static/fmld.zip) or [as a w2p](http://web2py.com/fmld/static/web2py.app.fmld.w2p).

commmenttor
Waleed

Would you consider writing your thoughts about writing in each of the frameworks? Which was easiest to user and which was the most fun to work on?

commmenttor
foobar 7th Nov., 2010

@massimo lol! dude stop poking around doing one man publicity pitches here there and everywhere.

commmenttor
Seun Osewa

You left out CherryPy??? It's the best minimalist framework.

commmenttor
Julien

I was wondering why pylons was left out and I would appreciate a brief summary of your experience with all those framework.

commmenttor
Shabda Raaj 8th Nov., 2010

If you fork on github and send me a pull request, I will include Pylons and CherryPy.

commmenttor
Jonathan 9th Nov., 2010

No TurboGears 2 ? :(

commmenttor
rosetta stone

Our website offers the Cheap Rosetta Stone on sale,such as these very popular kinds: Rosetta Stone Spanish,Rosetta Stone German,Rosetta Stone Italian and so on,besides,there are many friendly customers who left useful Rosetta Stone Reviews,which maybe the good guide for you!
All the Rosetta Stone are 100% satisfaction guaranteed,and free shipping.We guarantee its quality,and all money will be refund if the goods are not satisfied.
welcome to make a purchase.

commmenttor
j 14th Jan., 2012

so guys, which is the best, I'm hesitating between Flask and Tornado for a quite simple project, I've used web2py and I like it

commmenttor
ugg-boots-sale.ucoz.com

A bad workman quarrels with his tools.Don't be so modest.How about a drink tonight? It's against the rules to handle the ball in soccer.Shut up!I don't know if I'll have the patience.I don't know if I'll have the patience.I know all about it.i have become a beast of burden.he didn't bat an eyelid.

commmenttor
Neriboy

Nov23 I saw your post in the MT forums, I see you got November to show up. Once you get the hang of MT, I'm sure you'll enjoy it even more. Good Luck.

commmenttor

Reactions

colbyolson

That would be really interesting to see the details required for each framework in comparison to each other.

commmenttor
TY

Thanks to WSGI you can. For example, here's a handy page in Flask's (outstanding I might note) documentation on how you can run it on Tornado, Gevent and Gunicorn:http://flask.pocoo.org/docs/deploying/others/

commmenttor
Ixiaus

I've built my startup entirely in Python + Pylons (1.0). Pylons is wonderful, I really like it a lot and I'm excited about its future too (move to Pyramid which is basically repoze.bfg).The application I'm running is large, complex, and has quite a few moving parts. I run it under mod_wsgi in Apache and use the Paster server when developing on my local machine. I particularly love the unit testing harness for Nose that Pylons provides.

commmenttor
natrius

Neat, but you should check out PEP 8 at some point. An empty line between a decorator and the decorated function (flask) is confusing, and whitespace in keyword arguments just looks off.http://www.python.org/dev/peps/pep-0008/

commmenttor
LiveTheDream

You should maximize the use of ready-to-use extensions once you know how things work, whether yours or the community's.

commmenttor
rguzman

loosely coupled components are the way to goI disagree. Had you added "in some situations" I wouldn't. The point of the frameworks, which are heavily coupled components with many constraints, conventions and hidden parts of functionality is rapid prototyping. That means that you can go from 0 to something quickly without knowing all the details. For a large class of use-cases the ability to get something out there fast is more important than the technical debt you may incur by not knowing how everything is loaded. This is the case for a lot of new products, startups and such. On the flipside, if you have a very solid spec of what you're building (for example, if you are re-writing an already-existing piece of software with a browser-level test suite as spec so that it is easier to scale) then loosely coupled components are likely the way to go. And yes, as soon as scale comes into question loosely coupled components that you understand well are the way to do it. This just isn't always the case. Secondly, it is not clear whether the frameworks get in your way that much. I remember reading a blogpost about a shop replacing django bit by bit until there was no django. That seems pretty cool. On the other hand, there is disqus, which used django from the get-go, I think, and haven't swapped it out, but just built a lot of tools around it. On the third hand, there is probably a lot of sites that start with loosely coupled components and keep refining. They are all valid approaches. At the time you are starting it is usually unclear how to go about it. In general I agree that people should try to understand how their tools work, but there are only so many hours in a day, y'know?

commmenttor
newgame

Just a remark.The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so. I don't think the attribute micro relates to the size of the projects you can create with these frameworks but rather the way they are written: Keep the core small and rely on external libraries for specific functionality.

commmenttor
jokull

+1 for Flask. It very much gets out of your way. Interestingly it still feels like you have it both ways (batteries included but loosely coupled) as the series of extensions are high quality thin wrappers for good libraries - namely Babel, Fungiform and SQLAlchemy. For me this was a great introduction to these aforementioned libs.

commmenttor
justin_vanw

What is the point of making toy apps? Make a complex app that evolves over a period of 2 or so years, and then tell me how it went. Much of the time the framework where it is easiest to make a toy app is the one that has lots of hidden, implicit assumptions that come back to fuck you when you need the flexibility to do something that violates those assumptions.Having dealt with python frameworks for several years and developed several complex apps, I'm not willing to use anything other than werkzeug. It's lightyears ahead of than else out there (flask is werkzeug wrapped in shit you don't need with the intention of making it more popular). Pylons is also very nice, although it tries to do too much for you, and has too much magic for my taste. The context-local request and response objects in pylons are a double edged sword that I find cuts the wrong way too often.

commmenttor
derwiki

(Flask for its HTTP request handling functionality)++This is the _main_ reason I chose Flask to work on a new project. After using our in-house proprietary framework for a year and a half, I wanted to see if I could do any better. But the HTTP request part sounded boring. Enter Flask: it let's me grow the framework into exactly what I want it to be.

commmenttor
ubernostrum

Funnily enough, most of these frameworks' caching tools will set the appropriate outgoing headers for you. Which I'm pretty sure you know. I'm pretty you also know that "just set the HTTP cache headers" covers only a tiny fraction of the actual problem.

commmenttor
bboomslang

I guess you meant "not fiscally viable to use multiple machines" because I am quite sure last time I looked a lot of the queue packages came free.

commmenttor
TopCloudHosting

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x: http://bit.ly/cnYk3x

commmenttor
baselogic

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x: ... http://bit.ly/aX06Vp pt

commmenttor
baselogic

The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x# ... http://bit.ly/crrI0B pt

commmenttor
Purple_Design

I am so starving: #Web app in python frameworks. - The Agiliq Blog http://bit.ly/aAYajF

commmenttor
wPythonnews

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/9Py8yn

commmenttor
morenosan

I'm so starving es una aplicación web escrita 11 veces en 11 frameworks python. Gran idea. Muy educativo. http://goo.gl/UdWWB

commmenttor
softmodeling

RT@gsempe: The same app in various frameworks: appengine, flask, web.py, juno, bottle, itty, django http://j.mp/9SrW6x

commmenttor
StumblingRumble

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/aAYajF

commmenttor
aaloy

RT@morenosan: I'm so starving es una aplicación web escrita 11 veces en 11 frameworks python. Gran idea. Muy educativo. http://goo.gl/UdWWB

commmenttor
newsyc50

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

commmenttor
_olivier_

RT@johl: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

commmenttor
amicel

RT@johl: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

commmenttor
ActiveState

Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

commmenttor
newsyc100

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

commmenttor
jgalvez

You have a point. Let me elaborate my thoughts on Flask a bit further.Personally, my experience is that for rapid prototyping, there's nothing better than starting with the absolute minimum possible, and with a full-blown monolithic framework, the absolute minimum is, more often than not, too much. I prefer starting a project with a couple of files, like fabfile.py and app.py, than starting a project with a bunch of directories and tons of blueprinted configuration files. It's hard to explain why, I just feel it's a lot easier for me to evolve an idea, from a small prototype to a finished product, with this approach. I guess the cognitive signal to noise ratio is just higher that way. I know many people share this feeling, otherwise Sinatra and all these Python microframeworks wouldn't be getting so much attention. I think a good framework is like a good government, consistent, helpful, but with self-limiting interference. I think documentation is way more important than features. I'll take a well written web development patterns guide over a framework that does it all for me under the hood any day. The thing is that Flask tries to be both. Flask's documentation is absolutely fantastic. It is not surprise, of course, since it comes from the same guys who made the Sphinx documentation builder. I like conventions. I just don't think they ought to be mandatory. I see Flask as a genome of web applications, with pre-defined solutions and information on how to accomplish a series of things, but my application itself doesn't have to be a grown organism from the beginning, it can start small, like an embryo, and slowly grow in size. Flask gives you enough flexibility to employ conventions but also do things differently, to invent your own way, when you feel that you need to.

commmenttor
danenania

Yeah, I also prefer gluon. It had to be changed due to a copyright issue from what I gather. That said, I could give a hoot what a framework is named if I get work done quickly with it :)

commmenttor
mkramlich

that project's choice of name, web2py, drives me apeshit. i much preferred it when it was called gluon.web2py both (a) sounds way way too much like web.py, which predated it, and (b) it sounds like it's a successor to it -- which it is not, and (c) sounds like it's a conversion tool of some kind (following the whole "foo2bar" pattern in program naming). Whereas 'gluon': some small thing which binds the universe together. And it has personality!

commmenttor
mkramlich

web.py is similar in philosophy and verbosity, and probably older as well

commmenttor
suitter_bot

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/8CfWH

commmenttor
MatToufoutu

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

commmenttor
nekrox

@chglz tambien, voy a subir a github las cosas algo mas o menos así http://bit.ly/csaVbz

commmenttor
veverkap

RT@newsyc100: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, jun http://bit.ly/aDohEC (http://bit.ly/cR07Br) #guru

commmenttor
benmurray

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

commmenttor
jgalvez

You have a point. Let me elaborate my thoughts on Flask a bit further.Personally, my experience is that for rapid prototyping, there's nothing better than starting with the absolute minimum possible, and with a full-blown monolithic framework, the absolute minimum is, more often than not, too much. I prefer starting a project with a couple of files, like fabfile.py and app.py, than starting a project with a bunch of directories and tons of blueprinted configuration files. It's hard to explain why, I just feel it's a lot easier for me to evolve an idea, from a small prototype to a finished product, with this approach. I guess the cognitive signal to noise ratio is just higher that way. I know many people share this feeling, otherwise Sinatra and all these Python microframeworks wouldn't be getting so much attention. I think a good framework is like a good government, consistent, helpful, but with self-limiting interference. I think documentation is way more important than features. I'll take a well written web development patterns guide over a framework that does it all for me under the hood any day. The thing is that Flask tries to be both. Flask's documentation is absolutely fantastic. It is no surprise, of course, since it comes from the same guys who made the Sphinx documentation builder. I like conventions. I just don't think they ought to be mandatory. I see Flask as a genome of web applications, with pre-defined solutions and information on how to accomplish a series of things, but my application itself doesn't have to be a grown organism from the beginning, it can start small, like an embryo, and slowly grow in size. Flask gives you enough flexibility to employ conventions but also do things differently, to invent your own way, when you feel that you need to.

commmenttor
hackoder

I personally see django vs flask (or other microframework) as this:- Use a framework that has adequate components that are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework. - Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code. I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well. That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc. Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django. [1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month. Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.

commmenttor
hackoder

I personally see django vs flask (or other microframework) as this:- Use a framework that has adequate components but they are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework. - Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code. I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well. That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc. Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django. [1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month. Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.

commmenttor
MiltonDz

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://goo.gl/UdWWB

commmenttor
charlvn

I am so starving: Web app in python frameworks. http://agiliq.com/blog/2010/11/i-am-so-starving-same-web-app-in-various-python-we/

commmenttor
yurevich

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

commmenttor
ericmoritz

I think you'll find that many of the authentication and personalization problems will go away if you put the client's state in their browser and don't keep track of it on the server. If you'd look at the type of sites we build, news sites, most of the content is common among all users. The personalization stuff can be either stored in the browser using localStorage, Dojo.storage or cookies and inserted using javascript. That'll cut out the need to personalize the page on the server. If the personalization is not done on the server, then the content of the page becomes common among all users. Slap a two second expiration on it and Varnish in front of it and tada, Django doesn't have to mess deal with it for a few hundred requests. Other things, such as personalized lists of stories can be fetched on-demand using AJAX (if it needs to be included on a HTTP cached page). If it's personalized, google will never see it so there's no real reason to not pull it in using AJAX. Since the personalized list of stories is now a separate resource from a common list of stories. We can use the vary header to cache that page based on the auth tokens. If you're targeting a platform that can't keep local state, like a dumb phone, then you'd want to create a state-full layer on top of your stateless site/web service. You'd piece together data while fetching it through the proxy layer. All the common data will be cached and fetched really fast and all the personal stuff will be be as slow as it would be if fetched via AJAX. Invalidation is a hard problem. Often, the solution is to keep the expiration times short enough so that stale content doesn't stick around. The same is often true with memcached. I don't find myself having to delete keys from memcached because the with the data I'm caching, eventually consistent is good enough.

commmenttor
ericmoritz

I apologize if I gave that impression. I intended to mean that it is my impression that frameworks encourage the use of talking to memcached directly instead of encouraging the use of HTTP caching. I believe that it would be better if web developers started with HTTP caching (and a caching proxy) and only relied on memcached directly when absolutely needed.

commmenttor
grotgrot

Have a look at [this video](http://video.google.com/videoplay?docid=6297126166376226181) done a few years ago by a guy at NASA comparing various web frameworks including Java and Ruby ones. It is a nice presentation style and you may find some of the things he compares useful to look at too (restarts, errors, auth etc).

commmenttor
TopHackerNews

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/9UoTsc http://ff.im/-tlyVN

commmenttor
drahcir

that example needs to be cleaned up - it includes databases, error tickets, sessions, etc, which makes it look more complicated than the others.

commmenttor
Jeunito

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

commmenttor
blackthorne

RT@newsycombinator: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://j.mp/csaVbz

commmenttor
rlaksana

Writing a Web app in multiple python frameworks - Comparisons... - http://su.pr/1C5gI5

commmenttor
simonbowen

@marcfowler I wouldn't recommend Django, you'll start off with all their components, then rip them out later. Look here http://bit.ly/d2FLlc

commmenttor
ww2air

RT@justinvincent: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

commmenttor
justinvincent

Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

commmenttor
delicious50

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/cxrYxN

commmenttor
typeoneerror

RT@ActiveState: Comparing Python web (micro) frameworks: Writing a very simple webapp in Flask, web.py, bottle, juno and Django http://bit.ly/a9CCPy ^SR

commmenttor
omargomez

RT@justinvincent: Comparing Python frameworks: A simple webapp in Flask, web.py, bottle, juno ... http://bit.ly/drWFMR

commmenttor
saperduper

? I am so starving: Web app in python frameworks. - The Agiliq Blog http://is.gd/gZXBD

commmenttor
alanplum

You fail at reading comprehension, both in the title and the linked article.

commmenttor
ubernostrum

I think what you want to do here is *look at how this stuff is actually implemented*. For example, Django's cache middleware and its caching decorator for individual views (which are actually the same code) set the outgoing `Expires` header (and `ETag` if you're using those, and `Last-Modified` when needed). This gets you best of both worlds: things which respect HTTP caching will respect those headers. And things which don't will still get responses served out of server-side cache. Which is necessary: if you're under the impression that we live in a happy world where every client respects HTTP caching, brother, I've got some bad news for you...

commmenttor
ericmoritz

I'll have to add that the test I'm doing is not a comparison of framework speed but the failure of the way we all do caching at the moment.

commmenttor
delicious_n_hot

I am so starving: Web app in python frameworks. - The Agiliq Blog: http://bit.ly/fi6GEB #delicious #popular

commmenttor
futuramiah

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/B3Ybb #delicious

commmenttor
hot_delicious

I am so starving: Web app in python frameworks. - The Agiliq Blog http://dlvr.it/B3XzF

commmenttor
joshva

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/i8CDs9

commmenttor
KarenKinnaman

via Del.icio.us : I am so starving: Web app in python frameworks. - The Agiliq Blog: http://bit.ly/aAYajF #social #networking

commmenttor
deliciouspb

I am so starving: Web app in python frameworks. - The Agiliq Blog http://bit.ly/f0E6FX

commmenttor
akhenakh

Comparing #python web framework http://bit.ly/hTY3M3

commmenttor
Post a comment Name :

Email :

Your site url:

Comment :

© Agiliq, 2009-2012