Understanding Django Project Structure: manage.py, settings.py, urls.py, wsgi.py, and Apps

[Rajeev Bagra]

Understanding Django Project Structure: manage.py, settings.py, urls.py, wsgi.py, and App

After learning what happens when you run:

python manage.py runserver

the next step is understanding the structure of a Django project.

Many beginners see dozens of files and folders and wonder:

Which files are important?

What does each file do?

How do all these pieces work together?

In this lesson we’ll explore the core Django project structure and understand the role of each major component.

---

Creating a New Django Project

When you run:

django-admin startproject wiki

Django creates a structure similar to:

wiki/
│
├── manage.py
│
└── wiki/
├── init.py
├── settings.py
├── urls.py
├── asgi.py
└── wsgi.py

At first glance this may seem confusing, but every file has a specific responsibility.

---

The Big Picture

Think of a Django project as a company.

Company
│
├── Reception Desk
├── Rule Book
├── Directory
├── Communication System
└── Departments

In Django:

manage.py → Reception Desk
settings.py → Rule Book
urls.py → Directory
wsgi.py → Communication System
Apps → Departments

Let’s examine each one.

---

1. manage.py

Location:

manage.py

Purpose:

Command-line entry point for Django.

Examples:

python manage.py runserver
python manage.py migrate
python manage.py createsuperuser

Responsibilities:

Loads Django settings

Processes commands

Starts development tools

Executes management commands

Think of it as:

Reception Desk

Users submit requests and Django handles them.

---

1. settings.py

Location:

wiki/settings.py

Purpose:

Central configuration file for the project.

Example:

DEBUG = True

ALLOWED_HOSTS = []

INSTALLED_APPS = [
‘django.contrib.admin’,
‘django.contrib.auth’,
]

DATABASES = {
‘default’: {
…
}
}

This file controls:

Database settings

Installed applications

Middleware

Templates

Static files

Security settings

Think of it as:

Company Rule Book

Every part of Django follows these rules.

---

1. urls.py

Location:

wiki/urls.py

Purpose:

Direct incoming requests to the correct view.

Example:

from django.urls import path

urlpatterns = [
path(“admin/”, admin.site.urls),
]

Suppose a user visits:

/admin/

Django checks:

urlpatterns

and determines where the request should go.

Think of it as:

Company Directory

Someone arrives and asks:

“Where should I go?”

The directory points them to the correct department.

---

Example URL Routing

urlpatterns = [
path(“”, views.home),
path(“about/”, views.about),
path(“contact/”, views.contact)
]

Request:

/about/

Result:

views.about()

is executed.

---

1. wsgi.py

Location:

wiki/wsgi.py

Purpose:

Allows web servers to communicate with Django.

Example:

from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()

Most beginners never edit this file.

Its job is to create a WSGI application object.

Think of it as:

Telephone Operator

Requests arrive from a web server and are forwarded into Django.

---

What Is WSGI?

WSGI stands for:

Web Server Gateway Interface

It is a standard that allows:

Web Server
↔
Django

to communicate.

Without WSGI, servers wouldn’t know how to talk to Python applications.

---

1. asgi.py

Location:

wiki/asgi.py

Purpose:

Supports asynchronous communication.

Example:

from django.core.asgi import get_asgi_application

application = get_asgi_application()

ASGI stands for:

Asynchronous Server Gateway Interface

Used for:

WebSockets

Real-time chat

Live notifications

Async views

Think of ASGI as the modern version of WSGI.

---

1. init.py

Location:

wiki/init.py

Often empty:

Empty file

Purpose:

Tells Python that this directory is a package.

Without it, Python cannot properly import modules from the folder.

Most projects never modify this file.

---

What Are Django Apps?

A Django project contains one or more apps.

Create an app:

python manage.py startapp encyclopedia

Result:

encyclopedia/
│
├── admin.py
├── apps.py
├── migrations/
├── models.py
├── tests.py
├── views.py
└── init.py

An app is a self-contained feature or module.

Examples:

Blog App
Forum App
Shop App
Accounts App
Analytics App

---

Why Django Uses Apps

Instead of placing everything in one giant file:

Huge Project
↓
Impossible to manage

Django encourages:

Project
│
├── Blog App
├── Shop App
├── Accounts App
└── Analytics App

This improves:

Organization

Reusability

Maintainability

Team collaboration

---

Example: CS50 Wiki Project

Project:

wiki/

App:

encyclopedia/

Responsibilities:

Project

settings.py
urls.py
wsgi.py

App

views.py
models.py
templates/

The project provides infrastructure.

The app provides functionality.

---

How Everything Works Together

Imagine a user visits:

http://127.0.0.1:8000/wiki/Python

Flow:

Browser
│
▼
Web Server
│
▼
wsgi.py
│
▼
Django
│
▼
urls.py
│
▼
View Function
│
▼
Template
│
▼
Response
│
▼
Browser

At every step Django knows exactly what to do because each file has a dedicated responsibility.

---

Visual Overview

manage.py
│
▼
settings.py
│
▼
urls.py
│
▼
App Views
│
▼
Templates
│
▼
Browser

Meanwhile:

wsgi.py

or

asgi.py

acts as the gateway between Django and the outside world.

---

Key Takeaways

✅ manage.py is Django’s command-line control center.

✅ settings.py contains project configuration.

✅ urls.py routes requests to views.

✅ wsgi.py connects Django to traditional web servers.

✅ asgi.py enables asynchronous applications and WebSockets.

✅ Apps organize functionality into reusable modules.

✅ A Django project can contain multiple apps.

✅ Understanding the project structure makes the rest of Django much easier to learn.

---

Next Lesson

In the next tutorial we’ll explore:

Understanding Django Apps: models.py, views.py, templates, admin.py, and migrations

You’ll learn how a Django app is organized internally and how data flows from models to views and finally into HTML templates displayed in the browser.

[Author]

Posts