Could you explain more detailed differences between mod_wsgi and werkzeug? (SOS newbies)

Question

As I stated on the title, I'm currently feeling pretty uncomfortable of basic understanding of them.

As far as I know, mod_wsgi implemented WSGI specification which can be run under Apache web server.

It was coded in C language.

Another one, werkzeug is a kind of toolkit which have useful utilities. I also reviewed werkzeug can run simple service which is implemented within its sources(make_server in serving.py). I aware that werkzeug has useful features and simple server feature.

What I want to know it the below.

When using Flask like framework based on werkzeug under Apache web server, what does mod_wsgi do exactly?

werkzeug has also basic http server functionality which is don't need to be supported mod_wsgi.

Can anyone explain the differences between mod_wsgi and werkzeug ?

mod_wsgi and werkzeug has duplicated features from the perspective of web server.

Answer 1

WSGI stands for Web Server Gateway Interface, (mostly) defined by PEP 333 at http://www.python.org/dev/peps/pep-0333/ .

It is an effort by the Python community to establish a standard mechanism for web servers to speak to Python applications.

In theory, any wsgi compliant server (or extension to an existing web server) should be able to load and run any wsgi compliant application.

werkzeug is a web application framework which can run under a compliant WSGI server, such as Apache+mod_wsgi. It also contains a built-in development server that you can use for development.

---

WSGI can be very confusing at first, but it is actually pretty simple. The WSGI spec requires that your python application do the following:

1. define a callable named application
2. said callable should accept 2 parametes: (environ, start_response)
3. environ is a dictionary of environment variables
4. start_response is a callable that needs called to start the response

Once application is called, then it handles the request, builds the output, and:

1. calls start_response('200 OK', Headers)
2. return [content]

A simple WSGI app might look like this:

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                    ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

It is strongly suggested that you use an existing WSGI framework, as there are a lot of details involved in parsing HTTP requests, handling file uploads, encoding characters, etc...

Take a look at Bottle, Flask, werkzeug, AppStruct, etc...

Answer 2

mod_wsgi is a wsgi compliant python module that bridges python and apache. it lets you run applications coded to the wsgi spec under apache.

werkzeug is a wsgi utility library, used to build wsgi compliant applications. it ships with a development server.

there are a handful of Python Web Application Frameworks: Pyramid/Pylons, Flask, Bottle, Django, CherryPy, etc etc. They all implement the WSGI spec, which is the de-facto standard for building web applications in Python ( http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface )

Most web application frameworks ship with a debug-only or production-capable web server. When you have a WSGI app, you can serve via the library's app, through Apache via mod_wsgi, or using a 'pure' wsgi server like uWSGI , gunicorn, fapws, or twisted.

Most people I know will deploy a wsgi app like this:

• a lightweight server , like nginx, listens on port80
• the lightweight server serves static files itself
• the lightweight server proxies uWSGI requests to another server, which is often uWSGI, but sometimes apache+mod_wsgi or another. depending on the setup, the proxying can either be an http proxy or connecting to the uWSGI server directly or through a socket.

with that being said, to specifically answer your question, read the first paragraph of this docs page - http://werkzeug.pocoo.org/docs/serving/ :

There are many ways to serve a WSGI application. While you’re developing it, you usually don’t want to have a full-blown webserver like Apache up and running, but instead a simple standalone one. Because of that Werkzeug comes with a builtin development server.

For development reasons, or on a very low traffic site, you can just use the Werkzeug server. If you're deploying an application that will get a reasonable amount of traffic, you'll want something more robust.

mod_wsgi or uWSGI duplicate the serving features of Werkzeug , but they do it because they can do it considerably better - faster response times, lower memory , better concurrency, more stable, etc etc etc. the Werkzeug server is "good enough" for many uses, but its not "the best way" to serve a wsgi compliant app.