Django and web apps 101

If you're getting started with Django or you're willing to do so, you might find this post useful. I'll try to cover the main aspects of the framework while keeping it as brief as possible. I believe the following diagram describes the basic aspects of Django's data flow pretty accurately. After covering the details of each node, I’ll describe what would be in my opinion the basic recommended background, as well as some basic aspects about web development.

HttpRequest

Django will construct an HttpRequest object containing the data of the http request received from the web server. You can access all the information received in the request through the object attributes, e.g. request.method will contain the http method used to send it.

URLconfs

URLconfs are Python files matching url patterns (regular expressions) with views, so they are pretty much “telling” Django to what view they should send an http request, depending on what was the requested URL. They can also match a partial url with another URLconf that will match the rest of it. You will usually have a root URLconf file (determined by the ROOT_URLCONF setting) in the root directory of your Django project, which will point to one specific URLconf for each installed app. You can also use the regular expressions to extract information from the url and send it to the view. Since you have to pass the regex argument as a string, you should always use raw strings (just prepend an r) to prevent Python from escaping any character you might actually want to escape inside the regular expression.

Views

Views are essentially Python functions that take an HttpRequest object and return an HttpResponse object. There are also class based views, but they need to be called through a method. Views are usually defined in their own file, but they can even be defined and called directly from a urlconf file. A view can interact with the database, or not, and it can fill a template (or not). Views can gather data from the database or the requested URL and assemble a context, which is essentially a Python dictionary, fill a template with it and combine everything in an HttpResponse object.

Models

Models define the data for your app and its behaviour. Models are classes that inherit from django.db.models.Model, and each model corresponds to a database table, each attribute to a column and each instance of the model class to a row. Django provides a powerful API to interact with the database through models and translates every operation into the appropriate SQL code for your RDBMS.

Templates

A template is a text file, being an html file the most usual case. They allow you to put variables inside escape sequences ({{ variable }}), so that they can be substituted by the adequate content. They can also contain tags ({% tag %}), which control the logic of the template and allow you to do things such as iterations. Templates can even retrieve data from the database directly, but in a very limited way since (quoting Django’s documentation) “the template system is meant to express presentation, not program logic”.

Recommended background

Python, of course! The more you know, the better. I’m not saying you should know the standard library by heart though; if you’re comfortable with the built-in types and data structures, the main built-in functions and in particular object oriented programming, you should be fine. More advanced topics such as decorators can also be very useful.

HTTP
You should know at least a little bit about the GET and POST methods of the HTTP protocol. Having some notions about the other protocols of the TCP/IP suite, probably TCP and DNS in particular, will also be helpful if you plan to go into production in the future.

SQL
Web applications interact with databases, and relational databases have been around for a long time and they’re not going anywhere. Knowing how relational databases work is a must if you want to be a back-end developer, and that makes SQL pretty much mandatory (although knowing some of the relational algebra concepts behind it won’t hurt you either). Even though Django (luckily) will partially abstract you of the SQL going on behind the scenes allowing you to interact with your database in a much less verbose object oriented way, you should have an idea of what’s going on under the hood and how Django translates your CRUD operations. Django’s default DBMS is Sqlite3, a lightweight file-based database ideal for development environments. If you decide to move into production, you’ll have to switch to a more robust one, such as PostgreSQL, MySQL or Oracle. If you’re not too familiar with SQL, you might want to check Zed Shaw’s “Learning SQL the hard way” course (the DBMS used is also sqlite3) or the w3schools tutorial, where you’ll also be able to interact with a pretty large database.

Web servers
A web server is the program that will serve the requests of the clients, providing them the files they ask for (html/css/JavaScript files, images, etc). Django comes with a lightweight development web server. This server is meant to be used in a development environment, so the same thing applies here, you’re planning to go into production, you’ll have to move to a serious “battle tested” one, such as Apache or Nginx.

Recommended resources

• Django's official documentation, of course, in particular the Django tutorial. You might want to do this tutorial more than once; Django was written to make your life easier, but that doesn’t mean it’s not a very complex tool.
• Polls on steroids: this tutorial I’m currently working on might also be helpful after you’ve completed the aforementioned.
• Learn Django by example: some excellent tutorials where you’ll learn by doing. After the polls tutorial, this might be a good place to continue.
• Jeff Knupp’s and Simeon Franklin’s websites.