wheezy web: introduction

The key of success for any medium to high complexity system is in separation of domain concerns. Given that choice in architectural design for web framework, the development activities are split by distinct, non-dependent parts. The wheezy.web is a lightweight WSGI web framework and serves a glue purpose between various other packages developed under wheezy.* umbrella in loosely coupled way, it combines things essential for web application developer (presentation slides are here):

• routing - simple extensible mapping between URL patterns (as plain simple strings, curly expressions or regular expressions) to a handler; the mapping can include other mappings and constructed dynamically; reverse path by name
• domain model update from request input; validation
• transparent validation errors integration in HTML widgets
• authentication/authorization
• i18n (gettext)
• middlewares, response transforms, cookies, etc
• content caching, HTTP cache policy and cache profiles + cache dependency
• functional testing
• template engine agnostic, however brings wheezy.template. It offers HTML widgets for various template engines to make your code more readable and consistent (via template preprocessing to generate an optimal markup for given template engine)
• integration with pycrypto, lxml, python-memcached and pylibmc; the wheezy.captcha library is based on PIL
• documentation per package, tutorial, examples, demo
• Python 2.4 - 3.3+ ready

Python Web Caching Benchmark

Content caching is the most effective type of cache. This way your web handler is not executed to determine a valid response to user, instead one returned from cache. Since the operation is that simple, it should be the maximum possible speed your `real world` application capable to provide. There are several use cases when content caching is applicable:

• Site: the site content is changed rarely. The best case scenario is nginx+wsgi caching facilities, see more here.
• Handler: the site content caching policy vary, there are only few handlers were content caching is applicable.
• Managed (semi-real time): the site is dynamic, it is not permissible to cache a given output unless there is a way to invalidate content since some data changed, e.g. item price, new message arrived, etc. Read more here or give it a try.

How python web frameworks respond to this challenge? Only few (per documentation on official web site):

1. django 1.4.2
2. flask 0.9
3. wheezy.web 0.1.307

Web content caching benchmark is provided for two types of caching: memory and distributed. The cached content size is 8890 bytes (with applied gzip transform the content size down to 1086 bytes).

Python Templates Benchmark

Python template engines offer high reusability of markup code and the following features are used by content developers most of the time:

• Includes: useful to incorporate some snippets of content that in most cases are common to the site, e.g. footer, scripts, styles, etc.
• Extends: useful to define a master layout for the majority of the site content with placeholders, e.g. sidebar, horizontal menu, content, etc. The content developers extend the master layout by substituting available placeholders.
• Widgets: usually small snippets of highly reusable markup, e.g. list item, button, etc. The content developers use widgets to increase readability and enforce consistency of design.

We will examine all mentioned features above. Test is executed in isolated environment using CPython 2.7. Latest available versions (April 2, 2015):

1. django 1.8
2. jinja2 2.7.3
3. mako 1.0.1
4. tenjin 1.1.1
5. tornado 4.1
6. wheezy.template 0.1.159

Includes & Extends: in this test case an initial version of HTML content is refactored to use include and extend features of respective template engine.

Widgets: the test case is around how widget is built and used.

02-single - a widget is built in a way that loop is inside; 03-loop - a widget represent an item that is rendered in a loop.