web micro-framework battle!

Monday, 22 August 2011

webmicro-framework

Ba!le!Monday, 22 August 2011

akaRichard 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 offline 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)

What’s OUT?

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

• Template engine

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)

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.

• page view (GET /PageName)

• creation, editing (GET & POST /edit)

• redirect (GET /)

• not found (GET /favicon.ico)

The Contenders

• cgi+wsgiref• aspen.io• bobo• bottle• cherrypy• flask• 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.

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+wsgirefsimple WSGI appclass NotFound(Exception): passclass 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+wsgirefsimple WSGI app

These are the WSGI bits.

cgi+wsgirefsimple WSGI app

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

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+wsgirefurl 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+wsgirefserving HTTP

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

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 file!?!

boboindex

@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): if not storage.wikiname_re.match(name): raise bobo.NotFound('/%s' % name) self.name = name

@bobo.query('') def index(self): return wiki.render_page(name)

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.

boboindex

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): return wiki.render_edit_form(name)

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

boborunning 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 file? 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 figure how to get a WSGI application.

cherrypy

OK, so from the first 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!

cherrypyindex

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

def GET(self, name=None): if not name: raise cherrypy.HTTPRedirect("/FrontPage") if not storage.wikiname_re.match(name): raise cherrypy.NotFound('/%s' % name) return wiki.render_page(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.

cherrypyedit

class WikiEdit(object): exposed = True

def GET(self, name): return wiki.render_edit_form(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 config bit is a bit strange; ooh, automatic code reloading.; WSGI: I had to google and *then* look at the source to find out how to get a WSGI application: cherrypy.Application, cherrypy.request.wsgi_environ; MAGIC: minimal - just the cherrypy.request module global

web.py

DOCUMENTATION: great website, easy to get started

web.pyindex and /PageName

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

class page: def GET(self, name): if not storage.wikiname_re.match(name): raise web.NotFound('/%s' % name) return wiki.render_page(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 GET(self, name): return wiki.render_edit_form(name)

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 find 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 fiddly 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.pyserving

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-find web.application(...).wsgifunc(*middleware)

bottleindex and /PageName

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

@get('/:name')def display(name): if not storage.wikiname_re.match(name): abort(404, 'Not Found :/%s' % name) return wiki.render_page(name)

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

bottle/PageName/edit

@get('/:name/edit')def edit_form(name): return wiki.render_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).

bottleserving 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 files, adapters (eg werkzeug), SimpleTemplate, lots of convenience utilities

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

wiki = storage.Storage('contents')

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

@get('/:name')def display(name): if not storage.wikiname_re.match(name): abort(404, 'Not Found :/%s' % name) return wiki.render_page(name)

@get('/:name/edit')def edit_form(name): return wiki.render_edit_form(name)

@post('/:name/edit')def edit(name): if request.POST.get('submit'): wiki.store_page(name, request.POST['content']) 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!

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

ittyindex and /PageName

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

@get('/(?P<name>\w+)')def display(request, name): if not storage.wikiname_re.match(name): raise NotFound('/%s' % name) return wiki.render_page(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): return wiki.render_edit_form(name)

@post('/(?P<name>\w+)/edit')def edit(request, name): if request.POST.get('submit'): wiki.store_page(name, request.POST['content']) raise Redirect("/%s" % name)

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

ittyserving

run_itty()

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

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

flaskindex and /PageName

app = Flask(__name__)

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

@app.route('/<name>')def display(name): if not storage.wikiname_re.match(name): raise NotFound('/%s' % name) return wiki.render_page(name)

Where itty and bottle had a single default app that was being configured, 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

flask/PageName/edit

@app.route('/<name>/edit', methods=['GET'])def edit_form(name): return wiki.render_edit_form(name)

@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 “flask”; RESTful: request method in app.route() decorator which also takes URL

flaskserving

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

pestoindex and /PageNameapp = dispatcher_app()

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

@app.match('/<name:unicode>', 'GET')def display(request, name): if not storage.wikiname_re.match(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')def edit_form(request, name): page = wiki.render_edit_form(name) return Response(page)

@app.match('/<name:unicode>/edit', 'POST')def edit(request, name): if request.form.get('submit'): wiki.store_page(name, request.form['content']) 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.

pestoserving

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

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 figure things out. Having said that, the example program does talk about structure, ORM layers, templating, URLs and other handy things.

werkzeugindex and /PageName

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

def page(request, name): if not storage.wikiname_re.match(name): raise NotFound('/%s' % name) return wiki.render_page(name)

MAGIC: no magic

werkzeug/PageName/edit

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

def edit(request, name): if request.form.get('submit'): wiki.store_page(name, request.form['content']) raise RequestRedirect("/%s" % name)

werkzeugURL 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

werkzeugapplication 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

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.ioindex.html

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

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

aspen.iodirectory structure

.aspenindex.html%name/index.html%name/edit

Aspen sees the %name directory and assigns the first 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.htmlfrom aspen import Responseimport storage

wiki = storage.Storage('contents')^Lname = request.path['name']if not storage.wikiname_re.match(name): raise Response(404, '/%s' % name)page = wiki.render_page(name)^L{{ page }}

I had to go off to the Tornado docs to figure 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 filesystem paths

aspen.io%name/edit

from aspen import Responseimport storage

wiki = storage.Storage('contents')^Lname = 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. figure out what the request.body thing was and how to use it, and 2. figure 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.ioserving HTTP

from aspen import serverserver.main()

Put this in a file 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, flask:0, itty:0, pesto:0, web.py:0, werkzeug:0

Documentation

• good, downloadable: cgi+wsgiref, flask, 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,flask:1, itty:0, pesto:1, web.py:0, werkzeug:1

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

Ease of Use

• SIMPLE: pesto, itty, flask, web.py, bottle

• Could get complicated: werkzeug, cherrypy

• Complicated: aspen.io, bobo

• Just Plain Difficult: cgi+wsgiref

Avoiding Magic

• none: cgi+wsgiref, werkzeug, pesto

• WSGI not apparent: itty

• module-level: bottle, flask, web.py, cherrypy

• just plain odd: aspen.io, bobo

cgi+wsgiref:1, aspen.io:-2, bobo:-3, bottle:1, cherrypy:-1,flask:1, itty:1, pesto:3, web.py:0, werkzeug:2

RESTful

• bottle, flask, 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,flask:2, itty:2, pesto:4, web.py:1, werkzeug:3

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

• bottle, flask, pesto, cgi+wsgiref

• not obvious: itty, web.py, cherrypy

• manual: werkzeug

• unknown: bobo

• NO: aspen.iocgi+wsgiref:1, aspen.io:-4, bobo:-4, bottle:3, cherrypy: -1,

flask:3, itty:2, pesto:5, web.py:1, werkzeug:2

Python 3

• yes: cgi+wsgiref, bottle, cherrypy

• no: bobo, itty, web.py, pesto, werkzeug, flask, aspen.io

PyPy 1.5.0-alpha0 with GCC 4.0.1 on OS X

THEYALL

THEYALLRUN

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 Official* ScoresRank Framework Score

1 bottle 7

2 pesto 6

3 itty 4

4 flask, cgi+wsgiref 3

5 werkzeug 2

6 web.py 1

7 cherrypy 0

8 bobo -2

9 aspen.io -5Monday, 22 August 2011

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 file and compact application code. Awesome!

ExtrasFramework Sessions Caching Othercgi+wsgiref ✗ ✗

aspen.io ✗ ✗ static file servingbobo ✗ ✗

bottle ✗ ✗ templating, adapters, utilitiescherrypy ✓ ✓ static file serving, plugins

flask ✓ ✓ debugger, shell, werkzeugitty ✗ ✗

pesto ✓ ✓ utilities for testingweb.py ✓ ✗ openid, templating, form & db

werkzeug ✓ ✓ ATOM, secure cookies

web micro-framework battle!

dbapiext explicitness

provisioning

sqlalchemy

frameworks

core wiki

wiki page

db wrapper

frameworks

Technology

micro-services battle scars

distributed networked battle lab - natodistributed networked...

introduzione a micro framework

construindo um micro framework web em python

criando apis usando o micro-framework respect

php framework “battle”

micro framework 3.0

installation fr naia 2 micro - .net framework

introducing: net micro framework - emac inc

net micro framework development kit for device servers ·...

restoring peace in the battle of the forms: a framework

Краткий обзор . net micro framework

flyr php micro-framework

indian micro finance: evolution of regulatory framework

net micro framework

net micro framework の基礎

net micro framework for toppers

the .net micro framework and .net gadgeteer

metti il .net framework nel micro !

introduction to flask micro framework