Getting Started

Django Fundamentals — Getting Started
Django Fundamentals
Course 1 · Chapter 1 · Getting Started

🎸 Getting Started

Django's own tagline is "the web framework for perfectionists with deadlines" — and its defining trait is right there in the name of this chapter: it comes with almost everything already decided for you. Where FastAPI hands you a thin routing layer and lets you assemble the rest, Django ships an ORM, an admin interface, a templating engine, and a forms system on day one. This chapter gets a project running and makes that philosophy concrete.

Batteries-Included vs Minimal Core

You already know FastAPI's shape from the FastAPI Rebuild project — a handful of decorated functions and whatever libraries you chose to bring in yourself. Django starts from the opposite end:

FastAPI vs Django — Day One

FastAPI: Minimal Core
from fastapi import FastAPI app = FastAPI() @app.get("/") def read_root(): return {"message": "Hello"}

No ORM, no admin, no forms system, no templating — you choose and wire up each piece yourself (SQLAlchemy, Jinja2, Pydantic, ...).

Django: Batteries Included
django-admin startproject mysite cd mysite python manage.py startapp blog python manage.py runserver

Four commands and you already have an ORM, an admin interface, a templating engine, a forms system, and a migration tool — all part of the framework itself.

Convention Over Configuration

Like Rails' philosophy applied to Python — Django expects files in predictable places (models.py, views.py, urls.py) rather than asking you to decide the shape yourself.

The Trade-off

FastAPI is lighter and faster to learn end-to-end for a small API; Django's upfront structure pays off as an application grows past "a few endpoints."

📁 Project & App Structure

Django separates a project (the overall site configuration) from an app (a self-contained feature — blog, shop, accounts). One project can contain several apps:

mysite/ # the project ├── manage.py # command-line utility — migrations, runserver, shell ├── mysite/ │ ├── settings.py # all project configuration lives here │ ├── urls.py # the project's root URL routing table │ ├── wsgi.py # production entry point (sync) │ └── asgi.py # production entry point (async) └── blog/ # an app ├── models.py # database tables, as Python classes ├── views.py # request-handling logic ├── urls.py # the app's own URL patterns (optional but conventional) ├── admin.py # registers models with the auto-generated admin site └── migrations/ # auto-generated schema change history

Project vs App

A project is the whole site; an app is one reusable piece of it — a well-built app can even be dropped into a different Django project later.

manage.py

The command-line entry point for everything: runserver, migrate, startapp, shell, test — no separate CLI tool to install.

INSTALLED_APPS

A list in settings.py — an app's models, admin registration, and templates only take effect once it's added here.

settings.py

One file for database config, installed apps, middleware, templates, static files — versus assembling that configuration yourself across several files in FastAPI.

From Zero to a Running Server

The Four Commands That Start Every Django Project

# 1. Install Django pip install django # 2. Create the project (the outer "mysite" folder + config) django-admin startproject mysite cd mysite # 3. Create an app inside it python manage.py startapp blog # 4. Apply Django's own built-in migrations (users, sessions, admin tables) python manage.py migrate # 5. Run the development server python manage.py runserver # -> Starting development server at http://127.0.0.1:8000/

That migrate step is worth noticing: even before you've written a single model of your own, Django already has database tables it needs for its built-in admin, auth, and session systems — another concrete example of "batteries included."

💻 Coding Challenges

Challenge 1: Create Your First Project and App

Install Django, run django-admin startproject to create a project called library, then create an app inside it called catalog with startapp. List the files startapp generates and describe what each one is for.

Goal: Get comfortable with the project/app distinction and the files Django scaffolds automatically.

→ Solution

Challenge 2: Register the App

After creating the catalog app, explain (and demonstrate with a code snippet) exactly what has to change in settings.py before Django will recognize it, and what visibly fails if you forget this step.

Goal: Practice the INSTALLED_APPS registration step that's easy to forget coming from FastAPI's import-and-go style.

→ Solution

Challenge 3: Explore manage.py

Run python manage.py help and pick three subcommands you haven't used yet. For each one, write one sentence describing what it does and when you'd reach for it.

Goal: Build familiarity with manage.py as the single entry point for nearly every Django task, instead of memorizing commands one at a time as they come up.

→ Solution

💡 Real-World Tip: Forgetting INSTALLED_APPS

The single most common "why isn't this working" moment for a Django newcomer: creating an app with startapp and writing models or views in it, then finding they're invisible to migrations, the admin, or template loading. Django only looks at apps listed in INSTALLED_APPS in settings.py — startapp creates the files, but it does not register them for you.

🎯 What's Next

With a project and an app running, the next chapter covers how a request actually finds its way to your code: URL Routing — urls.py, path() patterns, and how Django's URL dispatch compares to FastAPI's decorator-based routes.