The internet contains tons of information out there about Django: The Web framework for perfectionists with deadlines . Why do we need one more article to add to it? The motivation of writing this blog post was a good friend of mine with whom I was about to start a project. We belong from different technological backgrounds. This was going to be his first time dealing with a Django application. And it was then when I realized that he was going though the same set of curious questions that I went through when I came across Django at my first time. This blog post is meant to serve as a reference point for myself as well as you guys out there to quickly be able to grasp some of the jargon that one would typically encounter while learning to develop a Django project.

Project Structure

At the time of writing this article, Django had released 2.2.6 and the Django Rest Framework had version 3.10.3 out. Both of them follow the same directory structure

Project/
├── Project
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

Let's go through the basic boilerplate files created:

__init__.py

According to the official documentation, Python defines two types of packages, regular packages and namespace packages. Regular packages are traditional packages as they existed in Python 3.2 and earlier. A regular package is typically implemented as a directory containing a __init__.py file. When a regular package is imported, this __init__.py file is implicitly executed, and the objects it defines are bound to names in the package's namespace. The __init__.py file can contain the same Python code that any other module can contain, and Python will add any additional attributes to the module when it is imported.

settings.py

The settings.py is a central configuration for all Django projects. Although settings.py uses reasonable default values for practically all variables, when a Django application transitions into the real world, one must take into account a series of adjustments to efficiently run the Django application.

urls.py

urls.py is the main entry point of a Django application. In most circumstances, Django uses the django.urls.path method to achieve url path matching mechanism. However, Django also offers django.urls.re_path method. The major difference between both these methods is that the path method is designed to perform matches against exact strings, whereas the re_path method is designed to perform matches against patterned strings based on regular expressions.

wsgi.py

WSGI is the Web Server Gateway Interface. It is a specification that describes how a web server communicates with web applications, and how the web applications can be chained together to process one request. WSGI is a Python standard described in detail in PEP-3333. The wsgi.py file contains the WSGI configuration properties for the Django project. WSGI is the recommended approach to deploy a Django aplication to production.

manage.py

The manage.py or django-admin commands can be used interchangeably as both serve the purpose of being Django's command-line utility. The main difference is that manage.py is used to run project-specific tasks, while django-admin is usually preferred for system-wide Django tasks.

Note: I'm planning to update this documentation over time. Stay tuned.