Python, Django and FastAPI for web developers

01Python in one page for web developers

Python uses indentation instead of braces, has no semicolons, and reads close to English. Variables are dynamically typed, but modern code adds type hints (name: str, -> list[int]) that tools like mypy or Pyright check before runtime. The core types you will use daily are str, int, float, bool, None, list, dict, tuple and set. Functions are defined with def, classes with class, and modules are just .py files you import. Python 3.14 is the current stable line (3.15 is due in October 2026's cycle), and you should always work inside a virtual environment so each project has its own dependencies. The fast, modern way to manage Python versions, environments and packages is uv; pip with venv still works everywhere.

• Truthy and falsy: empty list, empty string, 0 and None are all falsy.
• List and dict comprehensions replace most map and filter calls.
• async def and await exist, but much Python code is still synchronous.
• PEP 8 is the style guide; Ruff formats and lints it in milliseconds.

1from dataclasses import dataclass
2 
3@dataclass
4class Product:
5    name: str
6    price: float
7    tags: list[str]
8 
9def cheap(items: list[Product], limit: float = 10.0) -> list[str]:
10    return [p.name for p in items if p.price < limit]
11 
12items = [Product("Mug", 8.5, ["home"]), Product("Lamp", 40.0, [])]
13print(cheap(items))  # ['Mug']

02Setting up a Django project

Django is organised into a project (settings, root URLs, WSGI/ASGI entry points) and apps (self-contained features such as orders or blog). Each app has models, views, URLs, admin registration and migrations. Django 6.1 is the current feature release and 5.2 is the long-term support line; the next LTS, 6.2, is planned for April 2027. Django 6.0 added a built-in background tasks API, template partials and Content Security Policy support. The request flow is simple: the URL resolver matches a path, calls a view, the view uses models to read or write data and returns a response, often rendered with a template or serialised to JSON.

1uv init shop && cd shop
2uv add django
3uv run django-admin startproject config .
4uv run python manage.py startapp catalog
5# add "catalog" to INSTALLED_APPS in config/settings.py
6uv run python manage.py migrate
7uv run python manage.py createsuperuser
8uv run python manage.py runserver

03Models and the ORM

A model is a Python class that maps to a table. Each attribute is a field with a type and options, and Django generates migrations from changes to these classes. The ORM gives you QuerySets: lazy, chainable query builders that only hit the database when you iterate, slice or evaluate them. Relationships use ForeignKey, OneToOneField and ManyToManyField. Two methods matter most for performance: select_related joins single-valued relations in one query, and prefetch_related loads many-valued relations in a second query. Without them, a loop that touches product.category runs one query per row, the classic N+1 problem.

1from django.db import models
2 
3class Category(models.Model):
4    name = models.CharField(max_length=100, unique=True)
5 
6class Product(models.Model):
7    name = models.CharField(max_length=200)
8    price = models.DecimalField(max_digits=10, decimal_places=2)
9    category = models.ForeignKey(Category, on_delete=models.PROTECT, related_name="products")
10    created_at = models.DateTimeField(auto_now_add=True)
11 
12    class Meta:
13        indexes = [models.Index(fields=["category", "-created_at"])]
14 
15# One query with a JOIN instead of N+1:
16recent = Product.objects.select_related("category").filter(price__lt=50)[:20]

04The admin: a back office in ten lines

Django's admin reads your models and builds a full CRUD interface with search, filters, pagination and permission checks. Register a model, describe which columns to show and which fields to filter on, and staff users can manage data immediately. This is one of the main reasons teams choose Django for internal tools and content-heavy products. Treat the admin as a tool for trusted staff, not a customer-facing UI: put it behind a non-obvious path, require strong passwords or SSO, and use list_select_related so big tables do not trigger N+1 queries.

1from django.contrib import admin
2from .models import Product
3 
4@admin.register(Product)
5class ProductAdmin(admin.ModelAdmin):
6    list_display = ("name", "category", "price", "created_at")
7    list_filter = ("category",)
8    search_fields = ("name",)
9    list_select_related = ("category",)
10    ordering = ("-created_at",)

05JSON APIs with Django REST Framework

Django renders HTML by default. For JSON APIs, most teams add Django REST Framework (DRF). Its building blocks are serializers (convert models to JSON and validate input, like Laravel Form Requests plus API Resources), views or viewsets (handle HTTP methods) and routers (generate URLs). DRF also gives you authentication classes, permissions, throttling, pagination and a browsable API for development. Django Ninja is a newer alternative that uses type hints and Pydantic in a FastAPI-like style while keeping the Django ORM and admin.

1from rest_framework import serializers, viewsets, permissions
2from .models import Product
3 
4class ProductSerializer(serializers.ModelSerializer):
5    class Meta:
6        model = Product
7        fields = ["id", "name", "price", "category"]
8 
9class ProductViewSet(viewsets.ModelViewSet):
10    queryset = Product.objects.select_related("category").order_by("id")
11    serializer_class = ProductSerializer
12    permission_classes = [permissions.IsAuthenticatedOrReadOnly]
13 
14# urls.py
15# router = routers.DefaultRouter(); router.register("products", ProductViewSet)

06FastAPI: the async, typed alternative

FastAPI is a micro-framework built on Starlette (the ASGI toolkit) and Pydantic (validation). You declare request and response shapes as Pydantic models with type hints, and FastAPI validates input, serialises output and generates OpenAPI docs at /docs automatically. It is async-first, so it handles many concurrent I/O-bound requests well, which is why it is popular for ML model serving and API gateways. The trade-off: it has no ORM, admin, migrations or auth system built in. You pick SQLAlchemy or SQLModel, Alembic for migrations, and your own auth. Choose Django when you want a complete, opinionated product framework; choose FastAPI when you want a small, fast, typed API service.

1from fastapi import FastAPI, HTTPException
2from pydantic import BaseModel, Field
3 
4app = FastAPI()
5 
6class ProductIn(BaseModel):
7    name: str = Field(min_length=1, max_length=200)
8    price: float = Field(gt=0)
9 
10@app.post("/products", status_code=201)
11async def create_product(body: ProductIn) -> dict:
12    if body.name.lower() == "test":
13        raise HTTPException(status_code=422, detail="Reserved name")
14    return {"id": 1, **body.model_dump()}
15 
16# run: uv add "fastapi[standard]" && uv run fastapi dev main.py

07Running Python web apps in production

In development you use runserver or fastapi dev; never in production. For a synchronous Django app the classic setup is Gunicorn with several worker processes behind nginx. For async code (FastAPI, Django async views, WebSockets via Channels) you run an ASGI server such as Uvicorn, often managed by Gunicorn or as multiple Uvicorn workers. Static files are collected with collectstatic and served by nginx, a CDN or WhiteNoise. Settings come from environment variables, DEBUG must be False, ALLOWED_HOSTS must be set, and manage.py check --deploy lists missing security settings. Background work goes to Celery, RQ, Dramatiq or Django's new tasks API with a worker backend.

1# Django (WSGI) with 4 workers
2gunicorn config.wsgi:application --workers 4 --bind 127.0.0.1:8000
3 
4# FastAPI or Django ASGI
5uvicorn main:app --host 127.0.0.1 --port 8000 --workers 4
6 
7# Before each deploy
8python manage.py check --deploy
9python manage.py migrate --noinput
10python manage.py collectstatic --noinput

08How QuerySets really execute

A QuerySet is lazy: filter, exclude and order_by just build an internal query tree. SQL runs when you iterate, call list(), len(), bool(), slice with a step, or access an index. After the first evaluation, results are cached on that QuerySet object, so iterating it twice hits the database once, but calling .all() again creates a new QuerySet and a new query. exists() and count() run cheap targeted queries, so use them instead of len() when you only need a number. For huge tables, .iterator(chunk_size=2000) streams rows without caching them all in memory. F() expressions push arithmetic into SQL and avoid race conditions, and annotate with Subquery or aggregates keeps reporting logic in the database.

1from django.db.models import F, Count, Q
2 
3# Atomic increment in SQL, no read-modify-write race
4Product.objects.filter(pk=42).update(stock=F("stock") - 1)
5 
6# Aggregate in the database, not in Python
7Category.objects.annotate(
8    active=Count("products", filter=Q(products__price__gt=0))
9).order_by("-active")
10 
11# Stream a large export
12for p in Product.objects.only("id", "name").iterator(chunk_size=2000):
13    ...

09Transactions, locking and consistency

By default Django runs in autocommit mode: each query commits on its own. Wrap multi-step changes in transaction.atomic() so they succeed or fail together. For row-level locks, select_for_update() inside atomic issues SELECT ... FOR UPDATE, which is how you safely decrement stock or move money between accounts. Side effects such as sending an email or enqueuing a task should run only after the commit; transaction.on_commit() does exactly that, so a worker never processes a row that was rolled back. ATOMIC_REQUESTS wraps every request in a transaction, which is simple but holds transactions open during slow views, so many teams prefer explicit atomic blocks.

1from django.db import transaction
2 
3def reserve(product_id: int, qty: int) -> None:
4    with transaction.atomic():
5        p = Product.objects.select_for_update().get(pk=product_id)
6        if p.stock < qty:
7            raise ValueError("Out of stock")
8        p.stock -= qty
9        p.save(update_fields=["stock"])
10        transaction.on_commit(lambda: notify_warehouse.enqueue(product_id))

10Async in Python: what actually runs concurrently

Python's asyncio runs coroutines on a single-threaded event loop. Concurrency comes from awaiting I/O; while one request waits on the network, another runs. A blocking call (time.sleep, a synchronous DB driver, requests) stops the whole loop. FastAPI handles this nicely: plain def endpoints run in a thread pool, async def endpoints run on the loop. Django's async views work, and the ORM exposes async methods (aget, acreate, async for), but the database layer still largely runs in a thread via sync_to_async, so async Django mostly benefits I/O fan-out and long-lived connections, not raw query throughput. CPU-bound work needs processes or native code; Python 3.13 and 3.14 offer an optional free-threaded build that removes the GIL, but library support is still maturing.

11Scaling and hardening a Django deployment

Django scales horizontally: the app is stateless if sessions and cache live in Redis or the database, so you add Gunicorn processes and servers behind a load balancer. Connection count becomes the bottleneck first; set CONN_MAX_AGE for persistent connections, or Django 5.1+ native PostgreSQL connection pooling, or PgBouncer in front of the database. Cache expensive fragments and views with the cache framework backed by Redis. Read replicas are supported through database routers. On security, enable SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE and HSTS, configure SECURE_PROXY_SSL_HEADER only when your proxy sets that header, and keep the admin behind an unusual URL with MFA.

1# settings/production.py (excerpt)
2DEBUG = False
3ALLOWED_HOSTS = ["example.com"]
4SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
5SECURE_SSL_REDIRECT = True
6SESSION_COOKIE_SECURE = CSRF_COOKIE_SECURE = True
7SECURE_HSTS_SECONDS = 31536000
8DATABASES["default"]["CONN_MAX_AGE"] = 60
9CACHES = {"default": {"BACKEND": "django.core.cache.backends.redis.RedisCache",
10                      "LOCATION": "redis://127.0.0.1:6379/1"}}