My first web app (Python): use CGI, or a framework

Question

I don’t want to burden you all with the details, but basically I’m a 2nd year compsci student with no Web dev experience.

Basically I want to create a small “web app” that takes in input from a html form, have a python script perform some calculations, and re-display those results in your browser.

As of right now, I have the form and script built. However, when I try to test the form, instead of running the script, my browser tries to download it. To my understanding, this is a cgi script problem, and that I must create a web server in order to test this script.

And heres were I’m stuck. I know little to nothing about web servers and how to set them up. On top of that I’ve heard that GCI scripting is a thing of the past, and requires major overhead in order to run properly.

This leads to my questions. How do I go about completing my app and testing my cgi script? Do I install apache and mess around with it or should I be looking into something like google app engine? Are there other ways to complete this task without cgi scripts? Where do frameworks like Django fit into this?

Answer 1

Django, while being nice, all-encompassing and well-supported, is sometimes too much for a small web application. Django wants you to play by its rules from the beginning, you'll have to avoid things like the database and admin panels if you don't need them. It's also easier, with Django, to follow its project layout, even when it's too complex for a simple app.

The so-called micro frameworks might suit you better for your small app. They are built upon the opposite principle: use the bare minimum of features now, add more as you need them.

• Flask is based on Werkzeug WSGI library and Jinja2 templating (the latter is switchable), is extensively documented (with notes concerning virtualenv and stuff) and well-suited for small and larger apps alike. It comes bundled with an auto-reloading dev server (no need for Apache on your dev machine) and Werkzeug-powered interactive debugger. There are extensions for things like HTML forms and database ORM.

• Bottle is as small as a microframework can get, consisting of 1 (one) file, dev server included. Drop it into your project folder and start hacking. The built-in SimpleTemplate templating engine is switchable, but the dev server is flakier in comparison to Flask's. The documentation is less complete, and, in my opinion, the whole thing is less polished and convenient as Flask.

In both cases, you use dev server locally, and then deploy using WSGI, the server interface for Python web apps which both frameworks support. There are many ways to deploy a WSGI app, Apache mod_wsgi being one of the popular ones.

I'd totally go with Flask unless one dependency (Bottle) is better than three (Flask, Jinja2 and Werkzeug).

(There are many other frameworks as well, so wait for their users to come and tell about them. I'd suggest to avoid web.py: it works, but is full of magic, and is inelegant compared to Flask or Bottle.)

Answer 2

Django comes with its own server, but in your case i would recommend apache and mod_python since it seems to be a rather simple site you're building.

Setting up Apache is a breeze and a simple search on the web should give you all you need. You can find more information on mod_python here read up a little bit on it and then google after a tutorial that fits your needs.

Answer 3

It appears most python web development seems to be done by frameworks these days. There are a couple reasons for this:

1. a plethora of mature tools. Django has built in user auth, built in database management, built in sessions, built in just about everything ORM which lets you seamlessly supports a couple databases.

2. Built in webservers. The larger python frameworks like django and pylons have built in webservers. Django has a very simple webserver python manage.py startserver (that simple) That makes it extremely easy to create and debug applications. It is single threaded so dropping a debugger into it is painless

3. Huge communities. If you have a django question it will be answered very quickly the so community is huge.

The django tutorial will introduce you to all the major aspects of development. It is only 4 pages and you will be able to get your app going a lot simpler than having to read, learn and fiddle with an apache setup. https://docs.djangoproject.com/en/dev/intro/tutorial01/

Although django for right now might be overkill if your app is just going to be 1 form and a script to process it. Because of its seamless testing framework it is quite easy to grow any project. I have never used flask or bottle or the other microframeworks, but I would keep in mind where your project will be in the future.

As for where django fits into this, it is a full stack framework encompassing presentation (templates), data management (server orm), authentication, middleware, forms ... everything necessary to create a completely inclusive web application. Django and almost all other python frameworks implement the wsgi standard. It is an interface that allows for interoperation between webservers. http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface it is pretty dry and you will never have to interface it directly. That is what these frameworks do under the hood.

Answer 4

Why setup and maintain your own webserver if you can use app engine. It has an excellent SDK for testing your code. Here is an example https://developers.google.com/appengine/docs/python/gettingstarted/handlingforms

And Django you will find here : https://developers.google.com/appengine/docs/python/gettingstarted/templates I prefer to use Jinja for templating.

Answer 5

One way of getting to working webapp quickly is by first understanding, and then modifying, something like the App Engine "guestbook" example. This has the benefit that much of the otherwise necessary tedium of running a web server and setting up a database server (assuming you need persistence) is done for you. App Engine also provides a fairly flexible development environment. It's certainly not the only way to go, and I'll admit to bias in recommending it, but it's fairly low friction.

GCI scripting is hardly a thing of the past, though it's not what the cool kids are doing. CGI has the benefit, and the curse, of exposing more of the raw plumbing. It forces you to understand a lot about primitive (in the low-level sense) web architecture, but it's also a bit of a large bite to chew on if you have an immediate problem to solve that can solved by simpler means.