Web micro-framework BATTLE!

web

Monday, 22 August 2011

web
micro-framework


web
micro-framework

Ba!le!

aka


aka
Richard surveys the landscape
so you (probably) don’t have to


Introduction


I primarily develop systems for routing calls and texts, and provisioning phone numbers and things like that. I also maintain websites, but
I’m not talking about those today. I’m talking about HTTP as a layer for connecting my systems.

Introduction
• I write code for a telco



Introduction
• Lots of discrete system applications



Introduction
• Connected through HTTP



Introduction
• I write little HTTP servers all the time



Introduction
• I write little HTTP servers all the time
• I’ve written half a dozen micro-frameworks



What’s IN?


“standard lib”, access to form vars, redirection (with raise), OO/REST-ish app with GET/POST, WSGI so it’s easy to serve and get
middleware. Downloadable docs for ofﬂine development are a real bonus.

What’s IN?
• easy to understand and use
(docs, minimal magic, no surprises, terse)



What’s IN?
• HTTP request/response



What’s IN?
• URL routing (“RESTful”)



What’s IN?
• WSGI



What’s IN?
• WSGI
• PyPy and Python 3...


What’s OUT?


I like dbapiext / explicitness; SQLAlchemy works plenty well; templating is handled by other things (though some frameworks have
something built-in)

What’s OUT?

• Object-Relational Manager
(actually, any sort of DB wrapper)


something built-in)

What’s OUT?

• Object-Relational Manager
(actually, any sort of DB wrapper)
• Template engine


something built-in)

Who’s out?
• Mega Frameworks:
django, grok, pyramid, web2py, zope
• CubicWeb (never heard of it)
• milla (too young / incomplete)
• pump (too late to include)
• routes+webob (too complicated)

WIKI


In the following there's some core wiki code which is used to manipulate the wiki storage and render pages. When I wrote the wiki apps I
also implemented history and reversion to reinforce each framework’s approach, but I’ve left that out of these slides in the interests of
brevity.

WIKI

• page view (GET /PageName)


brevity.

WIKI

• creation, editing (GET & POST /edit)


brevity.

WIKI

• redirect (GET /)


brevity.

WIKI

• redirect (GET /)
• not found (GET /favicon.ico)


brevity.

The Contenders
• cgi+wsgiref
• aspen.io
• bobo
• bottle
• cherrypy
• ﬂask
• itty
• pesto
• web.py
• werkzeug


10 frameworks, cgi+wsgiref is my baseline

The Criteria
• documentation
• ease of use
• magic
• RESTful
• WSGI
• Python 3
• PyPy
• amount of typing
• size of the framework

Just to recap, this is what I’m looking for.

1.

cgi&wsgiref


DOCUMENTATION: just the standard library, EASE OF USE: a bit of work but not hard, EXTRAS: none, MAGIC: no, RESTful: no, WSGI:
yes

cgi+wsgiref
simple WSGI app
class NotFound(Exception):
pass
class Redirect(Exception):
def __init__(self, location):
self.location = location

def app(environ, start_response):
headers = [('Content-type', 'text/html')]
status = '200 OK'
try:
for p, m, c in urls:
if m != environ['REQUEST_METHOD']: continue
m = re.match(p, environ['PATH_INFO'])
if m is None: continue
response = c(environ, **m.groupdict())
raise NotFound
except NotFound:
status = '404 Not Found'
response = 'Not found: %s' % environ['PATH_INFO']
except Redirect, e:
status = '301 Moved Permanently'
headers.append(('Location', e.location))
response = ''
start_response(status, headers)
return response


No top-level app in wsgiref, so I had to write my own. This, by the way, is why I've written a half a dozen web frameworks.

cgi+wsgiref
simple WSGI app
status = '200 OK'
try:
raise NotFound
except NotFound:
except Redirect, e:
response = ''
return response


These are the WSGI bits.

cgi+wsgiref
simple WSGI app
status = '200 OK'
try:
raise NotFound
except NotFound:
except Redirect, e:
response = ''
return response


Given a list of potential actions containing a URL pattern to match, a request method and a callable, we see which one to call, if any.

cgi+wsgiref
actions
def index(environ):
raise Redirect('/FrontPage')

def page(environ, name):
if not storage.wikiname_re.match(name):
raise NotFound
return wiki.render_page(name)

def edit_form(environ, name):
return wiki.render_edit_form(name)

def edit(environ, name):
fields = cgi.FieldStorage(fp=environ['wsgi.input'],
environ=environ)
if 'submit' in fields:
wiki.store_page(name, fields.getfirst('content'))
raise Redirect("/%s" % name)

Handling forms is manual, of course.

cgi+wsgiref
url mapping

urls = [
('^/$', 'GET', index),
('^/(?P<name>w+)/?$', 'GET', page),
('^/(?P<name>w+)/edit$', 'GET', edit_form),
('^/(?P<name>w+)/edit$', 'POST', edit),
]


Finally we construct our list of potential handlers.

cgi+wsgiref
serving HTTP

server = wsgiref.simple_server.make_server('127.0.0.1', 8080, app)
server.serve_forever()


2.

bobo


bobo started out life as an awesome object publisher (get attributes and items) and then it became Zope. sadly as Zope grew, so bobo was
tainted and now it’s not the simple publisher it once was. DOCUMENTATION: limited and focused on The Bobo Way - EASE OF USE: it's
just not straight-forward, can't just create an app and publish it - I must publish a module ﬁle!?!

bobo
index

@bobo.query('/')
def index():
return bobo.redirect("/FrontPage")


Simple enough. MAGIC: bobo ... that’s the module. Decorating for scanning. I did have some transient, unexplained trouble with this
redirect ending up at “/FrontPage/”. There also doesn’t appear to be a redirect exception.

bobo
/PageName
@bobo.subroute('/:name?', scan=True)
class Page(object):
def __init__(self, request, name=None):
raise bobo.NotFound('/%s' % name)
self.name = name

@bobo.query('')
def index(self):


RESTful: quite confusing bobo.route()/bobo.subroute() request method in decorator. So here we’re setting up a “sub”route directing the
URLs starting with that pattern to the decorated class (any callable will do). Instances of the class will be created being passed the name
from the URL pattern. the docs seemed to imply that @bobo.query with no args would expose the function named - but that didn’t
work. scan? wha? well, without it the decorations in the class aren’t ... known.

bobo
index

AttributeError: Page instance has no attribute 'bobo_response'


without scan I get this bizarro error

bobo
/PageName/edit
@bobo.query('/edit', 'GET')
def edit(self):

@bobo.post('/edit', 'POST')
def do_edit(self, content, submit=False):
if submit:
wiki.store_page(self.name, content)
return bobo.redirect("/%s" % self.name)


Again the docs seemed to lie. @post needs that “POST” argument or it gets both GET AND POST. PRO: uses WebOb request/response.

bobo
running the app

if __name__ == "__main__":
import boboserver
boboserver.server(['-f', __file__])


And then we serve the application by pointing boboserver at the what now? We publish the module ﬁle? This is pretty wacky. WSGI:
kinda (paste deploy) - no idea how to plug into my own WSGI server. I poked and poked at the source and could not ﬁgure how to get a
WSGI application.

3.

cherrypy


OK, so from the ﬁrst example this looks to be a little different to others - kinda close to bobo by publishing objects and methods. But it’s
not RESTish. DOCS: pro: uses Sphinx, con: a bit light-on in some places. The default dispatcher doesn't make RESTish control easy so I'm
using a RESTish MethodDispatcher, but the only documentation for it is a simple example which doesn't really explain things in much
detail. I guessed at some of the semantics, and it worked!

cherrypy
index
@cherrypy.popargs('name')
class Wiki(object):
exposed = True

def GET(self, name=None):
if not name:
raise cherrypy.HTTPRedirect("/FrontPage")
raise cherrypy.NotFound('/%s' % name)

edit = WikiEdit()


Docs search found me the HTTPRedirect and NotFound which is nice.Yay Sphinx! “exposed” may be done in a bunch of different ways,
not explained clearly in one place AFAICT.

cherrypy
edit
class WikiEdit(object):
exposed = True

def GET(self, name):

def POST(self, name, content='', submit=None, cancel=None):
if submit:
wiki.store_page(name, content)
raise cherrypy.HTTPRedirect("/%s" % name)


cherrypy
the funky bit
conf = {
'/': {
'request.dispatch':
cherrypy.dispatch.MethodDispatcher(),
}
}

if __name__ == "__main__":
cherrypy.quickstart(Wiki(), '/', conf)


EASE OF USE: simple, though the conﬁg bit is a bit strange; ooh, automatic code reloading.; WSGI: I had to google and *then* look at the
source to ﬁnd out how to get a WSGI application: cherrypy.Application, cherrypy.request.wsgi_environ; MAGIC: minimal - just the
cherrypy.request module global

4.

web.py


DOCUMENTATION: great website, easy to get started

web.py
index and /PageName
class index:
def GET(self):
raise web.SeeOther("/FrontPage")

class page:
raise web.NotFound('/%s' % name)


RESTful: url mapping through ugly URLs tuple (url, name, url, name, ...) and handler named is class with request method methods GET(),
POST(), ...

web.py
/PageName/edit
class edit:

def POST(self, name):
f = web.input('content', submit=False, cancel=False)
if f.submit:
wiki.store_page(name, f.content)
raise web.seeother("/%s" % name)


DOCS: was hard to ﬁnd how web.input() worked; EASE OF USE: simple enough class-per-URL-match; Form doesn't support submit
buttons?! Forms are a bit of a ﬁddly way to get to simple form submitted data. For this simple case (very much like most of my uses) it's
actually easier to access the submitted information directly without involving the Form class through web.input().

web.py
serving
urls = (
'/', 'index',
'/(.+)/edit', 'edit',
'/(.+)', 'page',
)
app = web.application(urls, globals())

if __name__ == "__main__":
app.run()


MAGIC: url mapping through names looked up in globals? Ugh. module-level form input() global; EXTRAS: session, openid, utilities,
templating, form and db abstraction; WSGI: hard-to-ﬁnd web.application(...).wsgifunc(*middleware)

5.

bo!le


bottle
index and /PageName
@get('/')
def index():
redirect("/FrontPage")

@get('/:name')
def display(name):
abort(404, 'Not Found :/%s' % name)


PRO: SINGLE FILE! bottle.py; EASE OF USE: very simple; CON: MAGIC module global magic for request, response :-( PRO: Has ﬁrst-class
get(), post() as well as generic route() which conﬁgure a default app (you can also create other apps). DOCUMENTATION: very good,
downloadable

bottle
/PageName/edit
@get('/:name/edit')
def edit_form(name):

@post('/:name/edit')
def edit(name):
if request.POST.get('submit'):
wiki.store_page(name, request.POST['content'])
redirect("/%s" % name)


RESTful: get(), post() decorators which take URL. request.POST has the posted form vars (there’s also request.params which combines
GET and POST vars).

bottle
serving HTTP

if __name__ == "__main__":
run(host='127.0.0.1', port=8080)


WSGI: Had to look in the source but bottle.default_app.wsgi is WSGI. Bottle also has the concept of an app stack, but I didn’t look into
that and am not sure what the point is. EXTRAS: static ﬁles, adapters (eg werkzeug), SimpleTemplate, lots of convenience utilities

from bottle import get, post, request, run, abort, redirect
import storage

wiki = storage.Storage('contents')

@get('/')
def index():
redirect("/FrontPage")

@get('/:name')
def display(name):
abort(404, 'Not Found :/%s' % name)

@get('/:name/edit')

@post('/:name/edit')
def edit(name):
redirect("/%s" % name)

if __name__ == "__main__":
run(host='127.0.0.1', port=8080)


Seriously, that’s it. That’s all the overhead that bottle imposes when you write a web app with it!

6.

i!y


itty is really similar to bottle. They both aspire to the same simple API.

itty
index and /PageName
@get('/')
def index(request):
raise Redirect("/FrontPage")

@get('/(?P<name>w+)')
def display(request, name):
raise NotFound('/%s' % name)


get, Redirect and NotFound imported from itty (from itty import *) MAGIC module globals; DOCS: very little but straightforward and
good examples; EASE OF USE: simple; RESTful: get(), post() decorators which take URL;

itty
/PageName/edit
@get('/(?P<name>w+)/edit')
def edit_form(request, name):

@post('/(?P<name>w+)/edit')
def edit(request, name):
raise Redirect("/%s" % name)


request.POST simple enough; CON: Redirects appear in the log with tracebacks??!?

itty
serving

run_itty()


WSGI: itty.handle_request (the docs don't make this clear ... and *why* request._environ ??)

7.

ﬂask


Con: depends on two external libraries: the Jinja2 template engine and the Werkzeug WSGI toolkit. DOCS: very good, and downloadable,
though werkzeug references were tricky

ﬂask
index and /PageName
app = Flask(__name__)

@app.route("/")
def index():
return redirect("/FrontPage")

@app.route('/<name>')
def display(name):


Where itty and bottle had a single default app that was being conﬁgured, here we explicitly create our app. CON: There appears to be no
way to raise a redirect exception. NotFound needs to be imported from werkzeug directly. No way to return a NotFound result? EASE
OF USE: requirement to fall back to werkzeug sometimes makes things tricky

ﬂask
/PageName/edit
@app.route('/<name>/edit', methods=['GET'])

@app.route('/<name>/edit', methods=['POST'])
def edit(name):
if request.form.get('submit'):
wiki.store_page(name, request.form['content'])
return redirect("/%s" % name)


Con: in the quickstart, it wasn't clear where request came from. MAGIC: request is module-level global from “ﬂask”; RESTful: request
method in app.route() decorator which also takes URL

ﬂask
serving

app.run(debug=True)


Pro: debugger works really well; WSGI: the Flask object is a WSGI app; EXTRAS: werkzeug, test support, debugger, secure cookies, Jinja2,
shell

8.

pesto


pesto
index and /PageName
app = dispatcher_app()

@app.match('/', 'GET')
def index(request):
return Response.redirect("/FrontPage")

@app.match('/<name:unicode>', 'GET')
def display(request, name):
return Response.not_found('/%s' % name)
page = wiki.render_page(name)
return Response(page)


explicit app creation - nice. DOCUMENTATION: good; EASE OF USE: simple; MAGIC: no magic whatsoever; RESTful: request method in
app.match() decorator which also takes URL; unfortunately can’t just return the page contents from the function, have to wrap it in a
Response.

pesto
/PageName/edit
@app.match('/<name:unicode>/edit', 'GET')
page = wiki.render_edit_form(name)
return Response(page)

@app.match('/<name:unicode>/edit', 'POST')
return Response.redirect("/%s" % name)


Very, very similar to itty and bottle... the type is not optional - I just assumed unicode would be the default.

pesto
serving

httpd = simple_server.make_server('127.0.0.1', 8080, app)
httpd.serve_forever()


WSGI: app is a WSGI app; EXTRAS: utilities for testing, sessions, caching, wsgi

9.

werkzeug


DOCUMENTATION: very good, downloadable: The docs are a bit interestingly laid-out, with the sample program being overly complex to
start with, so I had to delve into the actual API docs to ﬁgure things out. Having said that, the example program does talk about structure,
ORM layers, templating, URLs and other handy things.

werkzeug
index and /PageName

def index(request):
raise RequestRedirect("/FrontPage")

def page(request, name):


MAGIC: no magic

werkzeug
/PageName/edit


raise RequestRedirect("/%s" % name)


werkzeug
URL mapping

url_map = Map([
Rule('/', endpoint=index, methods=['GET']),
Rule('/<name>/edit', endpoint=edit_form, methods=['GET']),
Rule('/<name>/edit', endpoint=edit, methods=['POST']),
Rule('/<name>', endpoint=page, methods=['GET']),
])


RESTful: Map with Rules having URL and request method type mapping to endpoint callable

werkzeug
application and serving
def application(environ, start_response):
request = Request(environ)
urls = url_map.bind_to_environ(environ)
try:
m, args = urls.match()
r = m(request, **args)
start_response('200 OK', [('Content-Type', 'text/html')])
return r
except HTTPException, e:
return e(environ, start_response)

if __name__ == "__main__":
from werkzeug.serving import run_simple
run_simple('localhost', 8080, application)


EASE OF USE: simple except writing my own WSGI app; EXTRAS: contributed code for sessions, ATOM, secure cookies and caching;
WSGI: had to write my own, but it was short

10.

a#en.io



Quite a different approach to things. Even though this is going against my "no templates" rule there is no way to use this framework
*without* using its templating...

aspen.io
index.html

from aspen import Response
^L
raise Response(301, headers={'Location': '/FrontPage'})
^L


EASE OF USE: wildly different and some things are inexplicably hard; EXTRAS: static ﬁle serving; MAGIC: the page break stuff
(initialisation, action, template) hurts understandability. Oh, aspen, "raise Response(301, headers={'Location': path+'/'})" really??!?

aspen.io
directory structure

.aspen
index.html
%name/index.html
%name/edit


Aspen sees the %name directory and assigns the ﬁrst part of the URL to the path variable “name”. Extra modules (storage, html, ...) have
to be placed in the hidden ".aspen" folder.

aspen.io
%name/index.html
import storage

^L
name = request.path['name']
raise Response(404, '/%s' % name)
page = wiki.render_page(name)
^L
{{ page }}


I had to go off to the Tornado docs to ﬁgure how to HTML escaping was handled (though I probably could've just tried and discovered
that it's not escaped by default). Not escaped HTML by default? RESTful: URLs map to ﬁlesystem paths

aspen.io
%name/edit
import storage

^L
name = request.path['name']
if request.method == 'POST':
if 'submit' in request.body:
wiki.store_page(name, request.body.one('content'))
raise Response(301, headers={'Location': '/' + name})
page = wiki.render_edit_form(name)
response.headers.set('Content-Type', 'text/html')
^L
{{ page }}


The documentation is *seriously* thin. I found myself having to read the source to: 1. ﬁgure out what the request.body thing was and how
to use it, and 2. ﬁgure out how to get a redirect back to the client. Oh, text/html isn’t the DEFAULT? RESTful: manually test for request
method type in handler

aspen.io
serving HTTP

from aspen import server
server.main()


Put this in a ﬁle in the aspen site’s directory. Or use the aspen command-line program. WSGI: appears to be no way to get a WSGI app.
I’ve given aspen a rough time here because it’s not really suitable for my purposes, but I can see how it’d actually be really nice to develop
a simple website with.

So, how do they rank?

• Let’s score them
• +1 or -1 on each of:
Documentation, Ease of Use, Avoiding
Magic, RESTful, WSGI, Python 3, PyPy and
SLOC

cgi+wsgiref:0, aspen.io:0, bobo:0, bottle:0, cherrypy:0,
ﬂask:0, itty:0, pesto:0, web.py:0, werkzeug:0


Documentation

• good, downloadable: cgi+wsgiref, ﬂask,
werkzeug, bottle
• good: pesto
• could be better: web.py, itty, cherrypy
• bad: bobo, aspen.io
cgi+wsgiref:1, aspen.io:-1, bobo:-1, bottle:1, cherrypy:0,


No “hello world” ... ? Hard to ﬁnd Redirect/NotFound, RESTful routing, form access, wsgi application?

Ease of Use

• SIMPLE: pesto, itty, ﬂask, web.py, bottle
• Could get complicated: werkzeug, cherrypy
• Complicated: aspen.io, bobo
• Just Plain Difﬁcult: cgi+wsgiref


Avoiding Magic

• none: cgi+wsgiref, werkzeug, pesto
• WSGI not apparent: itty
• module-level: bottle, ﬂask, web.py, cherrypy
• just plain odd: aspen.io, bobo
cgi+wsgiref:1, aspen.io:-2, bobo:-3, bottle:1, cherrypy:-1,


RESTful

• bottle, ﬂask, itty, pesto, web.py, werkzeug
• not obvious: bobo, cherrypy
• manual test method: aspen.io
• NO: cgi+wsgiref
cgi+wsgiref:0, aspen.io:-3, bobo:-3, bottle:2, cherrypy:-1,


This actually dictated the structure of my wiki code more than anything else.

RESTful

• Ignoring aspen.io there was 2 approaches:
• decorate callable
• listing maps directly to callable


WSGI

• bottle, ﬂask, pesto, cgi+wsgiref
• not obvious: itty, web.py, cherrypy
• manual: werkzeug
• unknown: bobo
• NO: aspen.io
cgi+wsgiref:1, aspen.io:-4, bobo:-4, bottle:3, cherrypy: -1,


Python 3

• yes: cgi+wsgiref, bottle, cherrypy
• no: bobo, itty, web.py, pesto, werkzeug, ﬂask,
aspen.io



PyPy



PyPy 1.5.0-alpha0 with GCC 4.0.1 on OS X

PyPy

THEY




PyPy

THEY
ALL



PyPy

THEY
ALL
RUN



wiki.py line/byte count
38/905 bottle
38/982 itty
41/1061 flask
43/1148 bobo
45/1071 web.py
45/1301 pesto
51/1267 cherrypy
55/1730 werkzeug
77/2126 aspen.io
78/2142 cgi+wsgiref



framework line count
593 itty
2441 cgi+wsgiref
2697 bottle
5600 aspen.io
6649 pesto
8044 bobo
10198 web.py
16563 werkzeug
27768 cherrypy
32245 flask



The Ofﬁcial* Scores
Rank Framework Score
1 bottle 7
2 pesto 6
3 itty 4
4 ﬂask, cgi+wsgiref 3
5 werkzeug 2
6 web.py 1
7 cherrypy 0
8 bobo -2
9 aspen.io -5

The scores, as determined solely by my own criteria and weighting.

OMGz0R a winner?

Bo!le!


Simple to use, great docs, RESTful and WSGI, Python 3. A single ﬁle and compact application code. Awesome!

Extras
Framework Sessions Caching Other
cgi+wsgiref ✗ ✗
aspen.io ✗ ✗ static file serving
bobo ✗ ✗
bottle ✗ ✗ templating, adapters, utilities
cherrypy ✓ ✓ static file serving, plugins
flask ✓ ✓ debugger, shell, werkzeug
itty ✗ ✗
pesto ✓ ✓ utilities for testing
web.py ✓ ✗ openid, templating, form & db
werkzeug ✓ ✓ ATOM, secure cookies

Web micro-framework BATTLE!

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Web micro-framework BATTLE!

Similar to Web micro-framework BATTLE! (20)

More from Richard Jones

More from Richard Jones (12)

Recently uploaded

Recently uploaded (20)

Web micro-framework BATTLE!