Skip to main content

Unit - 5

TITLE

Django Framework​

1. Introduction to Django Framework​

1.1 Overview of Django​

1.1.1 Definition of Django Framework​

Django is a high-level, open-source Python web framework used to build secure, scalable, and database-driven web applications quickly.

  • Follows MVT (Model–View–Template) architecture
  • Provides built-in tools to reduce development effort
  • Designed for rapid development and clean design

1.1.2 Django as High-Level Python Web Framework​

Django is called a high-level framework because:

  • It handles many low-level tasks automatically:

    • URL routing
    • Database interaction
    • Security handling
  • Developers focus on:

    • Application logic
    • Features
    • User experience

👉 Compared to low-level frameworks:

  • Less manual coding
  • Faster development

1.1.3 DRY (Don't Repeat Yourself) Principle​

Django follows the DRY principle, which means:

  • Avoid repeating the same code multiple times
  • Write reusable and modular code

Examples:

  • Reusable templates
  • Shared models
  • Centralized configuration

👉 Benefits:

  • Cleaner code
  • Easier maintenance
  • Reduced bugs

1.1.4 Built-in Features (Authentication, Admin, ORM, Security)​

Django comes with powerful built-in features:

1. Authentication System

  • User login/logout
  • Password hashing
  • Permissions and roles

2. Admin Panel

  • Auto-generated admin interface
  • Perform CRUD operations easily

3. ORM (Object Relational Mapping)

  • Interact with database using Python code
  • No need for raw SQL

4. Security Features

  • Protection against:

    • SQL Injection
    • Cross-Site Scripting (XSS)
    • Cross-Site Request Forgery (CSRF)

1.2 Features of Django​

1.2.1 Rapid Development Capability​

Django allows developers to build applications quickly due to:

  • Pre-built components
  • Minimal configuration
  • Built-in tools

👉 Reduces development time significantly


1.2.2 Reusability of Components​

Django promotes modular design:

  • Apps can be reused across projects

  • Components like:

    • Models
    • Views
    • Templates

👉 Encourages scalable architecture


1.2.3 Scalability and Security​

Scalability:

  • Can handle small to large applications
  • Used by large platforms (Instagram, etc.)

Security:

  • Built-in protections against common attacks
  • Secure authentication system

1.2.4 Database-Driven Application Support​

Django is ideal for database-based applications:

  • Stores and manages data efficiently

  • Supports multiple databases:

    • SQLite
    • MySQL
    • PostgreSQL

1.3 Django Architecture (MVT Pattern)​

Django follows the MVT (Model–View–Template) pattern.


1.3.1 Model​

1.3.1.1 Database Abstraction Layer​
  • Represents database structure
  • Defines tables using Python classes
1.3.1.2 Data Structure Definition​
  • Fields define table columns

Example:

from django.db import models

class User(models.Model):
name = models.CharField(max_length=100)
1.3.1.3 ORM Mapping​
  • Maps Python objects → database tables
  • Allows querying without SQL

1.3.2 View​

1.3.2.1 Request Handling​
  • Receives HTTP request from user
1.3.2.2 Business Logic Processing​
  • Processes data
  • Interacts with model
1.3.2.3 Response Generation​
  • Returns HTTP response

Example:

from django.http import HttpResponse

def home(request):
return HttpResponse("Hello Django")

1.3.3 Template​

1.3.3.1 Presentation Layer​
  • Handles UI (HTML pages)
1.3.3.2 Dynamic HTML Rendering​
  • Displays dynamic data
1.3.3.3 Template Tags and Variables​
  • Uses:

    • {{ variable }}
    • {% tags %}

Example:

<h1>Hello {{ name }}</h1>

1.4 Django ORM vs SQL​

1.4.1 SQL-Based Database Interaction Challenges​

Using SQL directly:

  • Requires writing complex queries
  • Database-dependent
  • Error-prone

Example:

SELECT * FROM users;

1.4.2 ORM Abstraction Benefits​

Django ORM simplifies database interaction:

User.objects.all()

Benefits:

  • No SQL needed
  • Cleaner syntax
  • Faster development

1.4.3 Database Independence​

ORM allows switching databases easily:

  • No need to rewrite queries

  • Works across:

    • SQLite
    • MySQL
    • PostgreSQL

1.4.4 Query Handling without Raw SQL​

  • Queries written in Python
  • Django converts them to SQL internally

👉 Improves:

  • Readability
  • Maintainability
  • Productivity

🎯 Key Points (Exam Focus)​

  • Django = high-level Python web framework
  • Follows MVT architecture
  • DRY principle reduces redundancy
  • Built-in features: Auth, Admin, ORM, Security
  • ORM replaces raw SQL
  • Model → data
  • View → logic
  • Template → UI
  • Supports multiple databases
  • Enables rapid development

2. Django Project Installation in Virtual Environment​

2.1 Prerequisites​

2.1.1 Python Installation​

Python must be installed before working with Django.

  • Django is a Python-based framework
  • Recommended version: Python 3.x

Check installation:

python --version

or:

python3 --version

2.1.2 pip Package Manager​

pip is used to install Python packages like Django.

  • Comes pre-installed with Python (usually)
  • Used to manage dependencies

Check pip:

pip --version

2.2 Virtual Environment​

2.2.1 Definition and Purpose​

A virtual environment (venv) is an isolated Python environment.

  • Keeps project dependencies separate
  • Prevents system-wide conflicts

2.2.2 Dependency Isolation​

Each project has its own:

  • Python packages
  • Library versions

Example:

  • Project A → Django 3.x
  • Project B → Django 5.x

👉 Both can run without conflict


2.2.3 Avoiding Version Conflicts​

Without virtual environments:

  • Updating a package may break other projects

With virtual environments:

  • Projects are independent
  • Safe upgrades

🧠 Virtual Environment Concept​


2.3 Creating Virtual Environment​

2.3.1 python -m venv Command​

Create a virtual environment:

python -m venv venv
  • venv = environment folder name
  • Creates isolated Python setup

2.3.2 Folder Structure (Include, Lib, Scripts)​

After creation:

venv/
│
├── Include/
├── Lib/
├── Scripts/ (Windows) / bin/ (Linux/Mac)
└── pyvenv.cfg
  • Include/ → header files
  • Lib/ → installed packages
  • Scripts/bin/ → executables

2.4 Activating Environment​

2.4.1 Activation in Windows​

venv\Scripts\activate

2.4.2 Activation in Linux/Mac​

source venv/bin/activate

👉 After activation:

  • Terminal shows (venv) prefix

Example:

(venv) user@system:~$

2.5 Installing Django​

2.5.1 pip install django​

Install Django inside the virtual environment:

pip install django
  • Installs Django locally (inside venv)
  • Does not affect system Python

2.5.2 Verifying Installation (django-admin)​

Check Django installation:

django-admin --version

👉 Displays installed Django version


🧠 Installation Flow​


2.6 Deactivating Environment​

2.6.1 deactivate Command​

To exit virtual environment:

deactivate
  • Returns to system Python
  • Removes (venv) from terminal

🎯 Key Points (Exam Focus)​

  • Virtual environment = isolated Python setup

  • Prevents dependency conflicts

  • Created using python -m venv

  • Activated using:

    • Windows → venv\Scripts\activate
    • Linux/Mac → source venv/bin/activate
  • Install Django using pip install django

  • Verify using django-admin --version

  • Use deactivate to exit environment

3. Phases in Django Project Creation​

3.1 Creating Django Project​

3.1.1 django-admin startproject Command​

A Django project is created using:

django-admin startproject myproject
  • myproject → name of the project
  • Creates the base structure for Django application

👉 This is the first step in Django development


3.1.2 Project Folder Structure​

After creation:

myproject/
│
├── manage.py
└── myproject/
├── __init__.py
├── settings.py
├── urls.py
├── asgi.py
└── wsgi.py
  • Outer folder → project container
  • Inner folder → actual Django project

🧠 Project Creation Flow​


3.2 Core Project Files​

3.2.1 manage.py​

3.2.1.1 Command Execution Interface​

  • Command-line utility
  • Used to interact with Django project

Examples:

python manage.py runserver
python manage.py migrate

3.2.1.2 Project Management Utility​

  • Performs administrative tasks:

    • Run server
    • Apply migrations
    • Create apps
    • Create superuser

👉 Central control file for Django project


3.2.2 settings.py​

3.2.2.1 Project Configuration​

  • Main configuration file
  • Controls behavior of project

Contains:

  • Debug mode
  • Installed apps
  • Middleware

3.2.2.2 Installed Apps​

Defines all apps used in project:

INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
]

👉 Add custom apps here


3.2.2.3 Database Configuration​

Defines database settings:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}

👉 Default database = SQLite


3.2.2.4 Static Files Configuration​

Defines static file settings:

STATIC_URL = '/static/'

👉 Used for:

  • CSS
  • JavaScript
  • Images

3.2.3 urls.py​

3.2.3.1 URL Routing Definition​

  • Maps URLs to views

Example:

from django.urls import path

urlpatterns = [
path('', views.home),
]

3.2.3.2 Mapping URLs to Views​

  • Connects user request → view function

Flow:


3.2.4 wsgi.py and asgi.py​

3.2.4.1 WSGI Interface​

  • Used for synchronous applications
  • Connects Django app with web servers (e.g., Gunicorn)
application = get_wsgi_application()

3.2.4.2 ASGI Interface​

  • Used for asynchronous applications

  • Supports:

    • WebSockets
    • Real-time apps
application = get_asgi_application()

🧠 WSGI vs ASGI​

FeatureWSGIASGI
TypeSynchronousAsynchronous
Use CaseTraditional appsReal-time apps
ExampleGunicornDaphne

3.3 Running Development Server​

3.3.1 python manage.py runserver​

Start the Django development server:

python manage.py runserver

Default:

  • URL → http://127.0.0.1:8000/

3.3.2 Server Output Interpretation​

When server starts, you see:

Starting development server at http://127.0.0.1:8000/
Quit the server with CTRL-C.
  • Indicates server is running
  • Shows accessible URL

3.3.3 Accessing Application in Browser​

Open browser and visit:

http://127.0.0.1:8000/

👉 Default Django welcome page appears


🎯 Key Points (Exam Focus)​

  • Create project using django-admin startproject
  • manage.py → project control tool
  • settings.py → configuration file
  • urls.py → URL routing
  • wsgi.py → sync deployment
  • asgi.py → async support
  • Run server using python manage.py runserver
  • Default server runs on port 8000

4. Creation of Apps and Their Structure​

4.1 Introduction to Django Apps​

4.1.1 Definition of App​

A Django app is a self-contained module that performs a specific function within a project.

  • Represents a feature or functionality

  • Examples:

    • Blog app
    • Authentication app
    • Product app

👉 A project is made up of multiple apps


4.1.2 Modular Structure of Django​

Django follows a modular architecture:

  • Each app is independent

  • Apps can be:

    • Reused across projects
    • Developed separately

👉 Benefits:

  • Scalability
  • Code organization
  • Maintainability

4.2 Creating an App​

4.2.1 python manage.py startapp​

Create a new app:

python manage.py startapp myapp
  • myapp → name of the app
  • Must be created inside project directory

4.2.2 App Folder Structure​

myapp/
│
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── views.py
├── tests.py
└── migrations/
└── __init__.py

🧠 App Structure Overview​


4.3 Important App Files​

4.3.1 views.py​

  • Contains view functions
  • Handles user requests
  • Returns responses

4.3.2 models.py​

  • Defines database structure
  • Contains model classes

4.3.3 admin.py​

  • Registers models for admin panel
  • Enables CRUD operations

Example:

from django.contrib import admin
from .models import User

admin.site.register(User)

4.3.4 apps.py​

  • Configuration file for the app
  • Contains app metadata

Example:

from django.apps import AppConfig

class MyappConfig(AppConfig):
name = 'myapp'

4.4 Views in Django​

4.4.1 Definition of View​

A view is a function that:

  • Receives HTTP request
  • Processes it
  • Returns HTTP response

4.4.2 Request-Response Cycle​


4.4.3 HttpResponse Usage​

from django.http import HttpResponse

def home(request):
return HttpResponse("Hello World")

4.4.4 Returning HTML Content​

def home(request):
return HttpResponse("<h1>Welcome</h1>")

4.5 URL Configuration​

4.5.1 urls.py in App​

Create a urls.py inside app:

from django.urls import path
from . import views

urlpatterns = [
path('', views.home),
]

4.5.2 path() Function​

Used to define URL patterns:

path('url/', view_function)

4.5.3 URL Pattern Mapping​

Maps URL → view function


4.6 Project-Level URL Integration​

4.6.1 include() Function​

Used to include app URLs in project:

from django.urls import include, path

urlpatterns = [
path('', include('myapp.urls')),
]

4.6.2 Linking App URLs to Main URLs​

  • Connects app routing to main project
  • Enables modular routing

4.7 Templates in Django​

4.7.1 templates Folder Creation​

myapp/
└── templates/
└── index.html

4.7.2 HTML Template Files​

Example:

<h1>Hello Django</h1>

4.7.3 Template Rendering Flow​


4.7.4 Template Rendering Methods​

4.7.4.1 loader.get_template()​
from django.template import loader
template = loader.get_template('index.html')

4.7.4.2 template.render()​
html = template.render({'name': 'Ankur'})

4.7.4.3 Returning HttpResponse with Template​
return HttpResponse(html)

4.8 App Registration​

4.8.1 Adding App to INSTALLED_APPS​

INSTALLED_APPS = [
'myapp',
]

4.8.2 settings.py Configuration​

  • Required for Django to recognize app
  • Enables models, templates, admin

4.9 Models and Database​

4.9.1 Model Definition​

from django.db import models

class User(models.Model):
name = models.CharField(max_length=100)

4.9.2 Fields (CharField, IntegerField, etc.)​

Common fields:

  • CharField
  • IntegerField
  • EmailField
  • DateField

4.9.3 Primary Key Behavior​

  • Django automatically creates:
id (AutoField, Primary Key)

4.10 SQLite Database​

4.10.1 Default Database Usage​

  • Django uses SQLite by default
  • No setup required

4.10.2 db.sqlite3 File​

  • Database stored as file:
db.sqlite3

4.11 Migrations​

4.11.1 makemigrations Command​

python manage.py makemigrations
  • Creates migration files

4.11.2 migrate Command​

python manage.py migrate
  • Applies changes to database

4.11.3 Migration Files (0001_initial.py)​

  • Stored in migrations/ folder
  • Contains schema changes

4.11.4 Migration Internals​

4.11.4.1 SQL Generation​
  • Django converts models → SQL queries

4.11.4.2 sqlmigrate Command​
python manage.py sqlmigrate myapp 0001
  • Shows SQL generated

4.11.4.3 Auto Increment ID​
  • Primary key auto-generated
  • Automatically increments

🎯 Key Points (Exam Focus)​

  • App = modular component of Django project

  • Create app using startapp

  • views.py → handles logic

  • models.py → database structure

  • admin.py → admin panel integration

  • urls.py → URL mapping

  • Templates → UI rendering

  • Register app in INSTALLED_APPS

  • SQLite is default DB

  • Migrations handle DB changes

  • Commands:

    • makemigrations
    • migrate
    • sqlmigrate

5. Working with Admin Console​

5.1 Introduction to Admin Interface​

5.1.1 Definition​

The Django Admin Interface is a built-in web interface that allows developers and administrators to manage application data without writing extra code.

  • Automatically generated by Django
  • Accessible through a browser
  • Used for backend management

👉 Saves time by eliminating the need to build custom admin panels


5.1.2 CRUD Operations Support​

Admin panel supports full CRUD operations:

  • Create → Add new records
  • Read → View existing data
  • Update → Edit records
  • Delete → Remove records

👉 All operations are performed through UI without coding


5.2 Admin URL Configuration​

5.2.1 admin.site.urls​

Django provides a built-in route for admin:

from django.contrib import admin
from django.urls import path

urlpatterns = [
path('admin/', admin.site.urls),
]
  • /admin/ → default admin route
  • admin.site.urls → connects admin system

5.2.2 urlpatterns Mapping​

  • urlpatterns maps URLs to views
  • Admin route is added to main URL configuration

Flow:


5.3 Creating Superuser​

5.3.1 createsuperuser Command​

Create admin user:

python manage.py createsuperuser

5.3.2 Username, Email, Password Setup​

During creation:

  • Enter username
  • Enter email (optional)
  • Enter password

Example:

Username: admin
Email: admin@example.com
Password: ********

5.3.3 Authentication Process​

  • Credentials stored securely in database
  • Passwords are hashed
  • Used to log into admin panel

👉 Only authenticated users can access admin


5.4 Admin Interface Usage​

5.4.1 Login Page​

Access admin panel:

/admin/

Login screen:

  • Username field
  • Password field

5.4.2 Dashboard Interface​

After login:

  • Displays list of registered models
  • Provides navigation panel

Example:

Users
Products
Orders

5.4.3 Data Management​

Admin allows:

  • Add new records
  • Edit existing records
  • Delete records
  • Search and filter data

Example model registration:

from django.contrib import admin
from .models import Product

admin.site.register(Product)

👉 Registered models appear in admin dashboard


🧠 Admin Workflow​


🎯 Key Points (Exam Focus)​

  • Django admin = built-in backend interface
  • Supports CRUD operations
  • Accessed via /admin/
  • Enabled using admin.site.urls
  • Superuser required for login
  • Create using createsuperuser
  • Models must be registered in admin.py
  • Provides easy data management without coding

6. Creating Views and URL Mapping​

6.1 URL Patterns​

6.1.1 Definition​

URL patterns define how incoming URLs are mapped to specific view functions in Django.

  • Stored in urls.py
  • Act as a routing system
  • Connect user requests → application logic

6.1.2 path() Function Usage​

The path() function is used to define URL routes.

Syntax:

path(route, view, name=None)
  • route → URL pattern
  • view → function to execute
  • name → optional identifier

Example:

from django.urls import path
from . import views

urlpatterns = [
path('', views.home),
]

🧠 URL Routing Flow​


6.2 Mapping URLs to Views​

6.2.1 Linking Views to URLs​

Each URL is connected to a specific view.

urlpatterns = [
path('home/', views.home),
]

👉 Visiting /home/ calls home()


6.2.2 Multiple Routes Handling​

Multiple URLs can be defined:

urlpatterns = [
path('', views.index),
path('about/', views.about),
path('contact/', views.contact),
]

👉 Each route maps to a different view


6.3 Dynamic URL Mapping​

6.3.1 URL Parameters​

Django allows dynamic values in URLs.

path('user/<str:name>/', views.user)
  • <str:name> → dynamic parameter

6.3.2 Passing Values to Views​

def user(request, name):
return HttpResponse(f"Hello {name}")

👉 URL value passed as argument


6.3.3 Regular Expression Handling​

6.3.3.1 Capturing Groups​

Earlier Django versions use regex:

from django.urls import re_path

re_path(r'^user/(?P<name>\w+)/$', views.user)
  • (?P<name>\w+) → captures value

6.3.3.2 Dynamic Routing Logic​
  • Enables flexible URL patterns
  • Matches complex paths dynamically

6.4 View Functions​

6.4.1 Basic Function-Based Views​

from django.http import HttpResponse

def home(request):
return HttpResponse("Welcome")

6.4.2 Returning HttpResponse​

  • Sends response back to browser
return HttpResponse("Hello User")

6.4.3 Rendering Templates with Context​

from django.shortcuts import render

def home(request):
return render(request, 'index.html', {'name': 'Ankur'})
  • render() loads template
  • Passes data using context

🧠 View Execution Flow​


6.5 Named URLs​

6.5.1 name Parameter​

Assign a name to URL:

path('home/', views.home, name='home')

👉 Used for referencing URLs dynamically


6.5.2 Reverse URL Resolution​

Django resolves URLs using names instead of hardcoding.

Example:

from django.urls import reverse

reverse('home')

👉 Returns:

/home/

6.6 Using URLs in Templates​

6.6.1 {% url %} Tag​

Used inside templates:

<a href="{% url 'home' %}">Home</a>

👉 Dynamically generates correct URL


6.6.2 Linking Pages Dynamically​

Example:

<a href="{% url 'user' name='Ankur' %}">Profile</a>

👉 Prevents hardcoding URLs


🎯 Key Points (Exam Focus)​

  • URL patterns map URL → view
  • path() defines routes
  • Dynamic URLs use <type:variable>
  • Values passed to view functions
  • HttpResponse returns output
  • render() used for templates
  • Named URLs improve flexibility
  • {% url %} used in templates
  • Reverse URL avoids hardcoding

7. Form Processing, Static and Media Files​

7.1 Static Files​

7.1.1 Definition​

Static files are resources that do not change dynamically and are served as-is.

  • Used for UI and frontend behavior
  • Do not depend on user input

Examples:

  • CSS stylesheets
  • JavaScript files
  • Images

7.1.2 static Folder Structure​

project/
│
├── static/
│ ├── css/
│ │ └── style.css
│ ├── js/
│ │ └── script.js
│ └── images/
│ └── logo.png

👉 Django looks for static files in the static/ directory


7.2 Static File Handling​

7.2.1 Adding CSS Files​

Example (static/css/style.css):

body {
background-color: lightblue;
}

7.2.2 Linking Static Files in Templates​

<link rel="stylesheet" href="{% static 'css/style.css' %}">

7.2.3 Template Tags for Static​

7.2.3.1 {% load static %}​

Must be added at top of template:

{% load static %}

7.2.3.2 {% static 'file.css' %}​
<link rel="stylesheet" href="{% static 'css/style.css' %}">

👉 Generates correct path to static file


🧠 Static File Flow​


7.3 Template Integration​

7.3.1 Applying CSS​

  • CSS is applied through linked stylesheet
  • Controls layout and styling

7.3.2 Styled Output Rendering​

  • Browser renders styled HTML

Example:

Page background becomes light blue

7.4 Form Processing​

7.4.1 Handling User Input​

Forms are used to collect user data.

Example HTML form:

<form method="POST">
<input type="text" name="username">
<input type="submit">
</form>

7.4.2 request Object Usage​

Django provides request object to access form data.

def submit(request):
data = request.POST['username']
return HttpResponse(data)

7.4.3 GET vs POST Handling​

7.4.3.1 request.GET​
  • Used for retrieving data from URL
  • Data visible in URL

Example:

name = request.GET.get('name')

7.4.3.2 request.POST​
  • Used for sending data securely
  • Data not visible in URL

Example:

name = request.POST.get('username')

🧠 Form Processing Flow​


7.5 Media Files​

7.5.1 Definition of Media Files​

Media files are user-uploaded files.

Examples:

  • Profile images
  • Documents
  • Videos

7.5.2 Difference from Static Files​

FeatureStatic FilesMedia Files
SourceDeveloperUser
ContentFixedDynamic
ExamplesCSS, JSImages, uploads

7.5.3 File Upload Handling​

Example model:

class Profile(models.Model):
image = models.ImageField(upload_to='images/')

Example form handling:

def upload(request):
if request.method == 'POST':
file = request.FILES['image']

👉 Files stored in media directory


🎯 Key Points (Exam Focus)​

  • Static files = CSS, JS, images (developer-defined)
  • Stored in static/ folder
  • Use {% load static %} and {% static %}
  • Forms collect user input
  • request.GET → URL data
  • request.POST → form data
  • Media files = user-uploaded files
  • File upload handled using request.FILES
  • Static ≠ Media files

8. Django App Deployment​

8.1 Introduction to Deployment​

8.1.1 Need for Deployment​

Deployment means making your Django application accessible to users over the internet.

  • Moves app from local machine → live server
  • Required for real-world usage
  • Allows access via domain/IP

Without deployment:

  • App runs only locally
  • No external access

8.1.2 Development vs Production​

FeatureDevelopmentProduction
ServerBuilt-in (runserver)WSGI server
PerformanceLowHigh
SecurityBasicStrong
Debug ModeEnabledDisabled

👉 Important:

  • runserver is not used in production

8.2 Deployment Preparation​

8.2.1 Configuration Settings​

Before deployment, update settings.py:

DEBUG = False
ALLOWED_HOSTS = ['yourdomain.com']
  • Disable debug mode
  • Set allowed hosts

8.2.2 Environment Setup​

  • Install dependencies:
pip install -r requirements.txt
  • Use virtual environment
  • Set environment variables for security

8.3 Deployment Platforms​

8.3.1 Hosting Services​

Common platforms:

  • Heroku
  • AWS (Elastic Beanstalk, EC2)
  • DigitalOcean
  • PythonAnywhere

👉 Provide:

  • Server infrastructure
  • Deployment tools

8.3.2 Server Setup​

Typical setup includes:

  • Web server (Nginx / Apache)
  • WSGI server (Gunicorn)
  • Database (PostgreSQL/MySQL)

👉 Architecture:


8.4 Running Django in Production​

8.4.1 Deployment Commands​

Run using Gunicorn:

gunicorn myproject.wsgi:application
  • myproject.wsgi → project module
  • application → WSGI callable

8.4.2 Server Execution​

  • Gunicorn handles requests
  • Nginx forwards requests to Gunicorn
  • Django processes and returns response

👉 Production flow is optimized and secure


8.5 Static Files in Production​

8.5.1 Static File Serving​

In production:

  • Static files are served by:

    • Nginx
    • Apache

👉 Not handled by Django directly


8.5.2 collectstatic Concept​

Command:

python manage.py collectstatic
  • Collects all static files into one directory
  • Used for efficient serving

Example:

STATIC_ROOT/

👉 Required before deployment


🎯 Key Points (Exam Focus)​

  • Deployment = making app live on server

  • Development server ≠ production server

  • Set:

    • DEBUG = False
    • ALLOWED_HOSTS
  • Use WSGI server (Gunicorn)

  • Use web server (Nginx/Apache)

  • Platforms: Heroku, AWS, etc.

  • Static files served separately in production

  • Use collectstatic before deployment