NOA Labs

Django Introduction

What Django is, installing it, starting a project, the project/app distinction, and the dev server.

What is Django?

Django is a high-level, batteries-included Python web framework, first released in 2005 and maintained by the Django Software Foundation. Where Flask hands you routing and templating and leaves the rest to you, Django ships with an ORM, a full authentication system, an auto-generated admin panel, a forms library, and a templating engine, all designed to work together out of the box. Django's own tagline captures the pitch well: "the web framework for perfectionists with deadlines."

This makes Django a strong default for larger, more conventional applications — content-heavy sites, internal admin tools, e-commerce platforms — where a consistent, productive structure across the whole team matters more than picking each piece individually.

Installing Django

Bash
python3 -m venv venv
source venv/bin/activate      # on Windows: venv\Scripts\activate
pip install django
Bash
python3 -m django --version
# 5.0.6

Starting a project

Django's django-admin command line tool scaffolds a new project:

Bash
django-admin startproject mysite
cd mysite

This generates:

Plaintext
mysite/
    manage.py
    mysite/
        __init__.py
        settings.py
        urls.py
        asgi.py
        wsgi.py

manage.py is the command-line entry point you'll use constantly (runserver, migrate, makemigrations, and more) — it's a thin wrapper around django-admin pre-configured for this specific project.

The project vs app distinction

Django draws a sharp line between two related but different concepts:

  • A project is the whole Django installation and its top-level configuration (settings.py, root urls.py) — there's exactly one per site.
  • An app is a self-contained module of functionality within that project — a blog, a store, a polls feature — meant to be focused and, ideally, reusable across projects.

A single project typically contains several apps. Create one with:

Bash
python3 manage.py startapp blog

This generates a blog/ directory with models.py, views.py, admin.py, a migrations/ folder, and more — the standard skeleton every Django app starts from. A newly created app doesn't do anything until you register it in the project's INSTALLED_APPS list in settings.py:

Python
# mysite/settings.py
INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "blog",   # your new app
]

Running the development server

Bash
python3 manage.py runserver

Visiting http://127.0.0.1:8000 shows Django's default "The install worked successfully!" welcome page — confirmation the project is wired up correctly before any of your own code runs. Like Flask's and FastAPI's dev servers, this is strictly for local development; production deployments run behind a real WSGI/ASGI server (Gunicorn, uWSGI, or Daphne/Uvicorn for async).

Common mistakes

  • Forgetting to add a newly created app to INSTALLED_APPS — its models, admin registrations, and templates are silently ignored until it's registered.
  • Confusing the outer mysite/ project folder with the inner mysite/ settings package that startproject creates with the same name — a common early source of import confusion.
  • Using manage.py runserver for anything beyond local development — it's explicitly not hardened or optimized for production traffic.

Interview questions

Q: What's the practical difference between a Django "project" and a Django "app"? A project is the entire site — its settings, root URL configuration, and the collection of apps that make it up; there's one project per deployment. An app is a focused, in-principle-reusable module of functionality (a blog, a polls feature, a payments module) that lives inside a project and gets registered in INSTALLED_APPS. A single project commonly contains many apps.

Q: Why is Django described as "batteries-included," and what's the trade-off? Django ships with an ORM, an admin site, authentication, a forms library, and templating all integrated and maintained together, so a team doesn't have to research, choose, and wire up separate third-party libraries for each of those concerns the way a Flask project typically does. The trade-off is less flexibility — swapping out a piece Django already provides (its ORM, for instance) works against the framework's grain, whereas a micro-framework like Flask is built around exactly that kind of substitution.