Understanding the Fundamental Django Framework Paradigms
Tags: django, python, webdev, tutorial
Published: 2021-01-11 18:05:22

Undoubtedly, the [Django web framework](https://djangoproject.com/) is powerful and flexible. At the same time, for beginners, it can be daunting to learn. I tried learning it several times by following "beginners" tutorials and, while successfully completing them, in the sense of having a working application, I never felt like the concepts clicked.

It turns out that Django has _two_ fundamental paradigms that you **must** understand (conceptualize) and internalize to learn and successfully use it:
1. The difference between "projects" (sometimes referred to as "sites") and "apps" in Django; and
2. The HTTP request/response cycle in Django and how data flows through the various files to display a page.
Let's look at each in more detail to see how they underpin the whole of Django, along with some additional references that you can explore.

## Projects and Apps in Django
The source of the confusion between _projects_ and _apps_ usually arises from the simple fact that what we often think of as an "application" (the overall, "big picture" package) is what Django refers to as the **project**. It is the **top-level container** for all of the work that makes up overall web application or site. Accordingly, sometimes, you'll also see the terms "project" and "site" used interchangeably in Django discussions.

Perhaps the best way to think about it is that, most often, immediately after you set up your Python virtual environment, the very first thing you do when developing with Django is to create a **project**. For example, if your new application/site name is *my_web_site*, you would do something like this (I'm using Linux):
```bash
mkdir my_web_site
cd my_web_site
python3 -m venv .venv
source .venv/bin/activate
pip3 install django
django-admin startproject my_web_site .
```
Note that the last line with the **`startproject`** command has `.` at the end, which tells `django-admin` to create the files in the current directory, `my_web_site`, instead of creating a new directory.

By comparison, **apps** in Django's terminology are simply the ways that your project is _logically_ subdivided and it provides _modularity_ to the project. For example, if you were building an ecommerce site, you might have separate apps for _products_, _customers_, _orders_, _shopping carts_, etc. Django will place each of the apps into a separate subdirectory under your top-level directory.

## HTTP Request/Response Cycle
First, don't be put off by some of the terms here. Essentially, this simply refers to how data flows through Django when someone interacts with a page, such as clicking a link or entering data into a form and pressing a _Submit_ button and having Django process the data. [HTTP](https://en.m.wikipedia.org/wiki/Hypertext_Transfer_Protocol) is the "language" that web applications (and all of the WWW) speak. The **request** is the data the comes into Django and the **response** is the data that Django sends out after processing the input request.

The basic request/response flow and the associated Django files are:

    +----------------+
    |      URLs      |
    |    urls.py     |
    +----------------+
             | 
             |
             |
             V 
    +----------------+
    |      View      |
    |  app/views.py  |
    +----------------+
             |  
             |                         
             |
             V                        
    +-----------------+
    | Model (optional)|
    | app/models.py   |
    +-----------------+ 
             |                         
             |                         
             |                         
             V 
    +-----------------+
    |    Template     |
    |  template.html  |
    +-----------------+

First, Django checks the _project-level_ `urls.py` file, which itself typically "includes" the contained (subordinate) _app-level_ `urls.py` files, as well, for the `urlpatterns` list to find the **routes** that are used. These routes represent patterns (called [regular expressions](https://en.m.wikipedia.org/wiki/Regular_expression), but you don't need to worry about that too much at the beginning) for the URLs of your site, such as `/home`, `/about`, etc. These routes tell Django what **views** then handle those particular routes.

Subsequently, Django directs the request to the appropriate view in the particular app (remember the difference between projects and apps in Django!). Each app in Django will typically have several views. The views typically obtain the content for the page from database **models**. (In _very_ simple sites, such as static web sites, like a blog, you may not have a database.)

Finally, Django takes **templates**, which _may_ be shared among/across apps, and combines the content with the styling and layout and, typically, some basic logic in the templates to render (build) the actual page for display. Templates provide benefits like allowing you to have standard menus, headers, and footers for your pages without re-creating them for each page.

When you starting out with Django, having _four_ files to manage just to display one page may seem like a lot of overhead. However, after you get accustomed to the pattern and flow and understand the paradigm, you will recognize the power and flexibility that it provides.

## Going Further
If you are just getting started with the Django Framework, I _highly_ recommend [_Django for Beginners_](http://leanpub.com/djangoforbeginners) by [William S. Vincent](https://wsvincent.com/). The book goes through five projects in detail in such a way that you repeat key elements until they are clear and natural.

Finally, the [Django documentation](https://docs.djangoproject.com/en/3.1/) itself is excellent. It requires some patience for newcomers, but working through the tutorial **after** you have done a couple of beginners' tutorials is recommended to solidify your understanding the core concepts.

I hope that this will help you on your journey to learn Django. Post your comments and question below.