Pages

▼

Thursday, 19 December 2013

Getting Started with WSGI

Deployment

Now where the application is "finished" it must be installed on the production server somehow. You can of course use wsgiref behind mod_proxy but there are also more sophisticated solutions available. Many people for example prefer using WSGI applications on top of FastCGI. If you have flup installed all you have to do is to defined a myapplication.fcgi with this code in:
#!/usr/bin/python
from flup.server.fcgi import WSGIServer
from myapplication import application
WSGIServer(application).run()
The apache config then could look like this:
<ServerName www.example.com>
    Alias /public /path/to/the/static/files
    ScriptAlias / /path/to/myapplication.fcgi/
</ServerName>
As you can see there is also a clause for static files. If you are in development mode and want to serve static files in your WSGI application there are a couple of middlewares (werkzeug and paste as well as "static" from Luke Arno's tools provide that) available.

NIH / DRY

Avoid the "Not Invented Here" problem and don't repeat yourself. Use the libraries that exist and their utilities! But there are so many! Which one to use? Here my suggestions:

Frameworks

Since Ruby on Rails appeared on the web everybody is talking about frameworks. Python has two major ones too. One that abstracts stuff very much and is called Django and the other that is much nearer to WSGI and called pylons. Django is an awesome framework but only as long as you don't want to distribute your application. It's if you have to create a webpage in no time. Pylons on the other hand requires more developer interaction and your applications are a lot easier to deploy.
There are other frameworks too but my experiences with them are quite bad or the community is too small.

Utility Libraries

For many situations you don't want a full blown framework. Either because it's too big for your application or your application is too complex that you can solve it with a framework. (You can solve any application with a framework but it could be that the way you have to solve it is a lot more complex than without the "help" of the framework)
For that some utility libraries exist:
  • Paste — used by pylons behind the scenes. Implements request and response objects. Ships many middlewares.
  • Werkzeug — minimal WSGI library we wrote for pocoo. Ships unicode away request and response objects as well as an advanced URL mapper and a interactive debugger.
  • Luke Arno's WSGI helpers — various WSGI helpers in independent modules by Luke Arno.
There are also many middlewares out there. Just look for them at the Cheeseshop.

Template Engines

Here a list of template engines I often use and recommend:
  • Genshi — the world's best XML template engine. But quite slow, so if you need a really good performance you have to go with something else.
  • Mako — stupidely fast text based template engine. It's a mix of ERB, Mason and django templates.
  • Jinja2 — sandboxed, designer friendly and quite fast, text based template engine. Of course my personal choice :D

Conclusion

WSGI rocks. You can simply create your own personal stack. If you think it's too complicated have a look at werkzeug and paste, they make things a lot easier without limiting you.
I hope this article was useful.

from http://lucumr.pocoo.org/2007/5/21/getting-started-with-wsgi/

at