Django Basics #1: What is Django — Why Django and Where It Fits Next to FastAPI

In the Modern Python FastAPI series, you combined type hints and async to build a small API with FastAPI. This Django Basics series uses the same Python but takes a fresh look at building a full-stack monolith — Django — from scratch. Across seven posts, you’ll build a small blog one piece at a time.

• #1 What is Django — Why Django and Where It Fits Next to FastAPI ← this post
• #2 Project setup — uv + django-admin startproject
• #3 Models and ORM basics — migration, ForeignKey, QuerySet
• #4 URL and Views (FBV)
• #5 Templates and static files
• #6 Forms and ModelForm
• #7 Django Admin and built-in authentication

After the seven Basics posts, the Intermediate seven — CBVs, ORM intermediate, signals, permissions — then the Advanced seven — async, caching, Channels, deployment — and finally the DRF in Practice six wrap up the track. 27 posts total. Long, but think of it as one project growing.

Django in one line #

Django is a full-stack web framework written in Python. The word “full-stack” is the heart of it. Routing, templates, ORM, migrations, forms, authentication, an admin page, security headers, static-file handling — almost every part you need to build a web app sits inside one package. The Django community calls this batteries included.

A short history #

Django started in 2003 at a small newspaper in Lawrence, Kansas — the Lawrence Journal-World. Two intern developers, Adrian Holovaty and Simon Willison, built the paper’s online content management system, and along the way they started abstracting the repetitive web-development tasks into a tool. That was the starting point.

On July 21, 2005, Django 0.90 was released as open source. The name comes from the jazz guitarist Django Reinhardt. Over almost 20 years since, Django has run on the back of large services like Instagram, Pinterest, Mozilla, Disqus, and Bitbucket. As of 2026, Django 5.x is the mainstream version, and this series targets 5.x.

MTV — Django’s MVC #

Django calls its own structure MTV (Model-Template-View). It’s basically the same as MVC — only the names differ.

“Wait — View is the Controller?” It’s confusing at first, but you only need to memorize it once. In Django, a View is a function (or class), and a Template is HTML.

What “full-stack” really means — what comes along #

What you get in a single Django install:

• ORM — Define DB tables as Python classes, query without writing SQL by hand
• Migrations — Auto-convert model changes into DB schema changes
• Admin — A management page that comes for free once you register a model (free CRUD UI)
• Authentication / authorization — User model, login/logout, groups/permissions
• Sessions / cookies — built-in
• Forms — HTML form definition, validation, rendering
• Template engine — {% if %}, {% for %}, inheritance
• Security — CSRF, XSS, SQL injection, clickjacking — defended by default
• Internationalization (i18n) — multilingual support
• Caching — backend abstraction (Redis, Memcached, DB, file)
• Email sending, messages framework, signals, middleware …

Pulling all of that together by hand or by stitching libraries takes weeks. Django has it all ready in a day. That’s Django’s philosophy — the work that needs doing is already done; you just write the business logic.

Django vs Flask vs FastAPI #

The same table you saw once in FastAPI #1, redrawn this time from Django’s point of view.

All three frameworks have their good place. It’s not better-or-worse — it’s about fit.

Where Django fits #

If two or more of the following apply, Django should be your first consideration.

• You need an admin page — internal tools, where operators must view and edit data directly
• A single full-stack monolith is enough — you don’t want to split frontend and backend
• DB is at the center — schema, relations, and transactions are the core of the business
• Auth/permissions are complex — users, groups, permissions, sessions all tangled
• Long-running operation — a strong chance you’ll maintain one codebase for 5+ years
• Large team — conventions and structure already in place make onboarding easy

Typical examples — internal ERP, learning management systems (LMS), content management systems (CMS), e-commerce, reservation systems, community/blog platforms.

Where Django is weak #

The reverse — these are places where other tools are a better fit.

• A pure async API in isolation — FastAPI is lighter and faster
• A single microservice slice — Django’s full-stack is too much overhead
• WebSocket-centric realtime — Django Channels can do it, but Node/Go/Elixir are more mature here
• Ultra-low latency / high call volume — the overhead of synchronous WSGI becomes a factor

That said, Django + DRF or Django 5.x async views can cover more of these cases than they used to — covered in Advanced #1 for async views and DRF #1 for DRF.

“Django or FastAPI — which should I learn?” #

Both. They’re different kinds of tools built on the same Python, and they can coexist. Combinations you actually see in production:

• Django for internal admin + FastAPI for the public API — both the rich admin features and the async/typed API
• A Django monolith + a separate FastAPI worker for async jobs — separation of responsibilities
• A single Django + DRF monolith — the most common starting point, then split as traffic grows

This series builds everything with Django alone, but the final DRF in Practice track also covers putting a REST API on top of Django.

What this series builds — a small blog #

The seven posts build a blog app. Users, posts, comments, tags, and an admin page. Each post stacks one more part on top.

When the seven Basics posts are done, you’re left with a small working blog. Intermediate / Advanced / DRF stack one more layer on top of that.

Vocabulary worth knowing up front #

Words you’ll encounter often, introduced here ahead of time.

• project — the top level with manage.py. One site = one project
• app — a reusable unit of functionality. One project consists of multiple apps. Examples: blog, accounts, payments
• model — a Python class that maps to a DB table
• migration — a file that translates model changes into SQL
• view — a request-handling function (or class). FBV / CBV
• template — an HTML template
• URLconf — URL pattern → view mapping
• manage.py — the entry point for every Django CLI command

Recap #

What this post nailed down:

• Django = a Python full-stack web framework, batteries included
• Started 2003 at the Lawrence Journal-World, open-sourced 2005, 5.x in 2026
• MTV = MVC (just different names)
• ORM, Admin, auth, forms, migrations, security — all in one package
• Where Django fits — full-stack, admin needed, DB-centric, long-running, large team
• Where FastAPI fits — async API, type-centric, micro
• The two aren’t competitors but different fits, and can be used together
• What this series builds — one small blog

In the next post (#2 Project setup), you’ll create a Django project with the same uv tool you saw in Modern Python FastAPI #1, and bring up the first page with manage.py runserver.